Re: What CDs and DVDs should we produce for lenny?
On Wednesday 19 March 2008, Gunnar Wolf wrote: > Anthony Towns dijo [Tue, Mar 18, 2008 at 03:39:05PM +1000]: > > (...) > > and the real question is where you say "if you really want the 23rd CD > > for mipsel, you're probably smart/dedicated enough to use jigdo". > > I completely agree with this. I don't think we must carry every CD for > every arch forever! > > BTW... 30 CDs are too many CDs. Just too fucking many. We could also > cut down on them - i.e. produce only the first 8 CDs per arch, and > have the rest only as DVDs. Yes, many people still do not have DVD > drives handy, but then again, 8 CDs + network access + a bit of > patience for the most obscure bits of software should be enough for > anybody... that assumes network access, which might be a reasonable assumption in the West, but that's not true everywhere (e.g. rural parts of India, Cuba, or most of Africa). In which case ordering a CD-set is way more practical (these also tend to be the places where they have older second hand pc's without a DVD-drive) > > The other thing we /could/ do is encourage people who've done > > successful Debian installs to help contribute by participating in a > > torrent after the fact -- you could do all sorts of things like have a > > FUSE filesystem that takes a (partial) mirror and a jigdo file and lets > > you see fake iso files, which you then seed via bittorrent, eg. You > > could automate that, so it's just a question like the popcon one: "Do > > you wish to participate as a torrent seed for other people installing > > Debian? Yes [No]" > > Ugh. Do you really want ISPs all over the world to start associating > Debian with evil communist pirate P2P filesharers? er, you do realise torrent is used for way more then that right? (for example there's now a scandinavian telivision station that's starting to distribute shows through bittorrent, we also already have debtorrent) -- Cheers, cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Re: gnome 1.x removal
On Tuesday 15 January 2008, Marc 'HE' Brockschmidt wrote: > "cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes: > > "As long as there's interest the software will stay alive" is one of > > the main tenets of Free Software. Consequently, IMHO, as long as > > there's people willing to maintain it, it shouldn't be removed > > regardless of how old it is. > > GNOME 1.x is neither maintained in Debian nor upstream. Noone has > stepped forward to keep it alive. The main reason that it's still in > Debian is that we don't clean up often enough. I had the impresion from this thread that people hadn't had the chance to step forward to take over maintenance yet, seems that impression was wrong, in which case I'm all for removal -- Cheers, cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Re: gnome 1.x removal
On Tuesday 15 January 2008, Pierre Habouzit wrote: > On Tue, Jan 15, 2008 at 01:10:26AM +, Thomas Bushnell BSG wrote: > > Don't start filing remove requests until other maintainers have a > > chance. Take the step of contacting those who maintain packages that > > depend on the libraries you want to remove, post RFAs instead of remove > > requests, and only post remove requests after people have had a goodly > > chance to take over maintenance themselves. > > Please, gnome 1.x is discontinued for years now, and the number of > packages that depends upon gnome-libs is fairly limited now, it's a > bearable task. FWIW the current list of package is: "As long as there's interest the software will stay alive" is one of the main tenets of Free Software. Consequently, IMHO, as long as there's people willing to maintain it, it shouldn't be removed regardless of how old it is. => If the current maintainer is no longer interested others should get the change to step forward and take over, and only if noone steps up it should be removed -- Cheers, cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Re: Please don't list available translations in the package description
On Friday 07 December 2007, Leo "costela" Antunes wrote: > Enrico Zini wrote: > > I'm thinking of filing bugs, but I'd like to get some feedback here > > first. > > While I agree it's an issue (albeit a small one), I think we shouldn't > file bugs for it while there's no better place to put this information. > It may reduce the objectiveness of some searches, but it is still > valuable information. Almost no packages currently do this, hence relying on the package description to check wether a package is localized for your language is completely unreliable. For a list of localised packages check http://www.debian.org/intl/l10n/po/ for your language, true it only cover's gettext localisations but that's 99% of all localisation in free software anyway (this misses some localised webapps but that's about it AFAIK) For a specific package you can also use apt-file or packages.debian.org to check for the presence of a .po file for your language. -- Cheers, cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Re: Bug#442008: Add /usr/local to $KDEDIRS
On Wednesday 05 December 2007, Mathieu Bouchard wrote: > I've been testing this for a couple of months and didn't found any > problems on my configuration. > > But since no other user asked for this for years and KDE3 will be replace > in the near future by KDE4 (i hope), I don't know if it is worth to > (maybe) break some configurations. > > And normally, users should install kde applications in the kde prefix or > in their local directory. See the desktop-profiles package which has the infrastructure bit for managing KDEDIRS (and several similar variables like XDG_CONFIG_DIRS, ...) In order to add /usr/local to KDEDIRS for all users on your machine, just install desktop-profiles and add the attached metadata file to /etc/destktop-profiles. As to wether setting KDEDIRS will cause problems or not, that will depend very much depend on what's in the directories added to KDEDIRS, most of the time it won't cause problems. -- Cheers, cobaco (aka Bart Cornelis) usr-local;KDE;/usr/local;;;Locally compiled KDE stuff signature.asc Description: This is a digitally signed message part.
Re: Reasons for recommends and suggests
On Saturday 19 May 2007, Manoj Srivastava wrote: > Well, for non-buggy packages, what you have is an issue of > trusting the maintainers judgement. In that case, you also have to > trust that the maintainer comes up with a correct, and properly > formulated explanation in under one line; which correctly emphasizes > the importance of the dependency relationship. > Unless you are a $Deity, or have conducted an extensive > analysis, this is a matter of judgement. By putting things as > recommends, the maintainer is saying, yes, it is a good thing to > install these packages together. > If you think the maintainers judgement is off, and have some > proof, file a bug to reduce the depndency. > > > Anyway, it was just an example out of many. For non-core packages, > > Recommends often add functionality that I'll never use but the package > > maintainer uses them daily. Why should I install it then? > > You don't have to. But you are saying you do not trust the > maintainers judgement, so asking in 80 characters or so why things are > needed is not likely to help. I have to strongly disagree with the opinion that this shows distrust in the maintainers judgement for 2 reasons IMO: 1) wanting more information is (in itself) in no way a sign of distrust 2) maintainers make decisions that are supposed to be reasonable to a regular user. However not everyone is a regular user, and in situations where one isn't, you might want to reexamine the decisions made. Not because of trust issues, but simply because some of the underlying assumptions might not apply Informing people is a Good Thing. So what if only a small percentage of our users will ever use the extra information, I don't see how the existence of that information would cause any problems -> so as long as somebody is willing to do the work for providing it I don't see the problem with supporting a standard system for putting the information in the user's hands. -- Cheers, cobaco (aka Bart Cornelis) pgpLOZBAJvqHP.pgp Description: PGP signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote: > Thus, I assume that not only novice consumers have the need for > improving desktop software and bugs seen fixed. > > However, Debian dosen't officially support and embrace any way to do > this. Watching for new version, You're on Your own. > Yes, if software works well, then changes are not wellcome. That's why I > suggest the desktop softwares upgrades to be "non-mandatory", however > officially supported. Each stable version has the explicit aim of being a platform with as little changes as possible. As you pointed out this sucks when the software you need is not mature enough to meet your needs yet. On the other hand for those users for whom that same software does meet the need this is a boon. As long as progress is made upstream in meeting your needs this problem inevitably fixes itself with time. With each stable version meeting the needs of a bigger group of users. Depending on what software in stable doesn't meet your needs your best option may be one of: 1) use stable with backports/manually compiled software/selected packages from testing 2) use testing (or a snapshot of it) 3) use another distro (e.g. ubuntu/kubuntu/xubuntu, ...) As a project we should aim to make 1 en 2 as easy and problem free as possible, and there's definately room for improvent there. But this is a hard problem lots of people are trying/have tried to improve. (witness things such as volatile, backports, CUT-releases, updated d-i releases, ...) -- Cheers, cobaco (aka Bart Cornelis) pgpfbMIW75h2c.pgp Description: PGP signature
Re: how long is 'pending'
On Wednesday 16 May 2007, Neil Williams wrote: > How long should bugs be tagged pending in advance of an upload? To me pending means, a fix is applied and will be in the next upload/release (hence no further triaging needed on this bug). It says nothing about when the upload with the fix will take place -- Cheers, cobaco (aka Bart Cornelis) pgpwUqztPou16.pgp Description: PGP signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote: > > Do you realize Debian's stable is classified as this: > > > > Stable means stable package list. No changes in API and ABI > > names or versions. This means no newer versions will ever make > > it into "stable". It is in "maintenance mode". This makes a > > very good setup for those wishing for "Rock Solid" machines. Doesn't > > crash. "too many" comes from the "Windows World", does not typically > > apply to Debian's Linux. > > No changes, no newer versions => dosen't crash? It's simply not true. > For example, the Debian Woody used an ancient version of Mozilla. _Very_ > crashy one, compared with newer versions that came few months later. > Noone could call that "stable" one. you're still missing the point here: - the point is _not_ that software in stable isn't buggy - the point is that software in stable doesn't change -> this ensures that it won't be buggy in new ways => thus making sure that what works, keeps working => thus making sure that ones you have a workaround, that keeps working to In short stable is about not getting any unexpected surprises/changes in how software behaves. -- Cheers, cobaco (aka Bart Cornelis) pgpQlXQjQvnll.pgp Description: PGP signature
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
On Monday 09 April 2007, Steve Langasek wrote: you don't believe that software will continue to push forward our > minimum hardware requirements, the way it has for the past decade or so? > What do you think is the minimum memory required to run a "comfortable" > desktop system (or workstation) today? How does that compare to the > minimum memory requirements at the time sarge was released? woody? lessened for KDE with respect to both woody and sarge: a pentium 2 333 Mhz and 128 MiB RAM are about minimum for a workable KDE 3.5 (I have a pentium 2 333 Mhz, with 196 MiB running, it works just fine as a low-end desktop-system) -- Cheers, cobaco (aka Bart Cornelis) pgpnbU5kZIVi3.pgp Description: PGP signature
Re: Attempted summary and thoughts
On Tuesday 27 March 2007, Mark Brown wrote: > On Tue, Mar 27, 2007 at 01:27:55PM +0200, cobaco (aka Bart Cornelis) wrote: > > On Tuesday 27 March 2007, Russ Allbery wrote: > > > *what's* in it. Just because it has a patch tag doesn't mean it's > > > necessarily any higher-quality of a bug unless it's been triaged. > > > > It may not be higher quality, but it almost definately is higher > > effort. > > > > Correspondingly the frustration on part of the bug/patch submitter when > > there's no response at all will be higher also. > > In my experience the correlation between the patch tag and the quality > of the report is fairly weak. that wasn't the poin I was trying to make :) > Often a clear and lucid bug report that outlines the required fix won't > have the patch tag because it hasn't got an a literal patch. > Often a patch is the first thing someone thought of and has serious > problems or requires noticable effort to understand due to a lack of > commentary. the point I was attempting to get across is that: - somebody supplying a patch is somebody who'se actively _trying_ to help. -> supplying a literal patch obviously is not the only way to do this (you outlined another class above), it's just one way that's easily spottable because of the patch tag - the fact that someone is actively helping find a solution is a Good Thing, we want to avoid having people who do that feel ignored -> this is one case where it is especially important to get some kind of reaction to the bug (Note: this does not necessarily meen speedy resolution of that patch and/or bug) => When this is not happening the package needs help badly Automatically orphaning such packages has problems as Russel pointed out, but a "needs co-maintainers"/"needs hijacking" list of packages where DD's can be more aggressive in jumping/taking over in seems a good idea IMO. -- Cheers, cobaco (aka Bart Cornelis) pgpntQR2AJ3Y5.pgp Description: PGP signature
Re: Attempted summary and thoughts
On Tuesday 27 March 2007, Russ Allbery wrote: > > If so, what action do you think should be taken in the case where those > > bug reports are not addressed by the package maintainer? > > Someone should triage the bug and remove the tag if the patch isn't > adequate. An untriaged bug is an untriaged bug -- we don't really know > *what's* in it. Just because it has a patch tag doesn't mean it's > necessarily any higher-quality of a bug unless it's been triaged. It may not be higher quality, but it almost definately is higher effort. Correspondingly the frustration on part of the bug/patch submitter when there's no response at all will be higher also. > So I agree wholeheartedly with the idea that bug triage is important, but > it doesn't always happen and that's why we're having this conversation. > I agree that one can infer from the existence of untriaged bugs that not > all the package maintenance we want is happening. But the one and only > one solution to that is to get more people working on the package or make > more time for the existing maintainers to work on the package when a maintainer is completely ignoring bugs with patches, he's essentially ignoring people who are trying to help (or at least that's how the bug submitter is likely to interpret it). That's something the project should obviously discourage, doubly so on packages that need help. > and orphaning the package does not magically accomplish this. > I'm willing to support being more aggressive than we currently are about > changing maintainers when someone else steps up and is willing to do the > work, but I'm not willing to support any proposal that automatically > orphans packages where there's no one waiting to work on it who is being > blocked by the current maintainer. I don't think that actually > accomplishes anything useful. We don't have to orphan the package to > know that it's in trouble -- there are many other metrics that can be > used for that. instead of orphaning before there's a new maintainer, maybe we need a "needs co-maintainer" or "may be hijacked" tag? -- Cheers, cobaco (aka Bart Cornelis) pgpy5erGJ56Vs.pgp Description: PGP signature
Re: Results for General Resolution: Altering package upload rules
On Friday 23 March 2007, Ben Finney wrote: > Lars Wirzenius <[EMAIL PROTECTED]> writes: > > On pe, 2007-03-23 at 10:32 +0100, BALLABIO GERARDO wrote: > > > Debian Project Secretary wrote: > > > > At the end of voting, with 313 Ballots resulting in 260 votes from > > > > 257 > > > > > > developers, "General Resolution: Altering package upload rules" has > > > carried the day. > > > > > > Please forgive me if this is a stupid question, but how can there > > > be more votes than voters? > > > > As far as I know: multiple votes from the same voter are allowed, > > the latest one received is counted. > > That's just it: if what you say is the explanation, then *more than* > "the latest one received" is counted. > If it's not counted, why is it counted (i.e. appearing in the count of > votes)? AIUI your confusing 2 different counts: - the count of "# valid votes made" - the count of "# valid votes taken into account", which is only the last valid vote for every developer. if there's people who changed their vote, only their last vote is counted to determine the outcome of the resolution, but they still made 2 votes (or more if they changed their minds more then once -- Cheers, cobaco (aka Bart Cornelis) pgpRz5YTdddKo.pgp Description: PGP signature
Re: Huge cache dirs in $HOME
On Wednesday 14 March 2007, Josselin Mouette wrote: > Le mercredi 14 mars 2007 à 09:45 +0100, Bernhard R. Link a écrit : > > Against those grotesque > > .fonts.cache-1 files (which are not only cache that should not be in > > /home, but also system dependent thus even more do not belong there) > > running fc-cache as root on all hosts regulary helps. > > The system font cache is now located in /var/cache/fontconfig. The user > font cache is for fonts in ~/.fonts, and I fail to see why it should be > outside ~. the original suggestion was to have everything follow the freedesktop basedir spec for the caching location, note that this spec defaults to the location $HOME/.cache (or whatever the $XDG_CACHE_HOME env var points to) -- Cheers, cobaco (aka Bart Cornelis) pgpGpQZ9csTYU.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Thursday 08 March 2007, Pierre Habouzit wrote: > It will likely be one of my last post on that matter because I feel > that valuable contributors left it long ago. gee, thanks for the (probably unintented as the above statement includes yourself) implied insult > You're (not you Matthias, You the other people with those ideas) take > the problem from the wrong side. The question is not about _how_ to > attract people, > but how did people that are now valuable contributors were attracted to > what they do right now. When you'll know that we will be able to improve > those things so that it gets even more attractive than now. err ... logical flaw above "look at how current contributors got attracted, and improve on what attracted them" is a particular solution to the question "how do we go about attracting people" Also as I've pointed out several times in this thread now: _I_ got attracted as contributor to Debian because I saw a mail asking for help with something small and easy (and that gave an easy step-by-step on how to get involved with that). -> the approach of sending mails asking for help that you've labeled pointless is an example of exactly what you say you're looking for above. > Just know that none of the suggestions made so far would have helped me > more when I was searching who/what to help, it would even have bored me. point to keep in mind is that "people are different, respond to different things, and take different approaches" -> periodically asking in different ways makes sense, as does trying to making sure that whatever the path somebody might take to getting involved. That someone is likely to notice your request for help. > shouting for help everywhere is like noise: it's absurdly painful, and > will itch people way too much. There's a difference between 'shouting' and 'politely and invitingly asking for help' (or to use your metaphore noise has levels it's not a question of noise or no noise). As usual the key is balance: - you don't want to overdo it by constantly spamming every available channel. - But you don't want to go to the other extreme either. For example (and please keep in mind that I do _not_ mean this to be an attack on either you or the kde team) the information in this thread tells me that it has been over a year since the single mail from the kde team asking for help with bugs. Now that undoubtfully doesn't give the entire picture, as I'm sure there've been RFH's in other channels then debian-kde. Still it's been over a year since the last RFH on the debian-kde list, that's a rather long time. IMO a frequency of a couple (say 3 or 4) of RFH's per year would seem more likely to produce results. That said nobody is forcing you or any other DD/packaging team to ask for help in any particular way (or at all). So no need to get all worked up, if you find the suggestions in this thread impractical/useless then by all means ignore them, they're only suggestions. -- Cheers, cobaco (aka Bart Cornelis) pgpmiLjSYEQZo.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Wednesday 07 March 2007, Pierre Habouzit wrote: > On Tue, Mar 06, 2007 at 12:49:56PM -0500, Matthias Julius wrote: > > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > > Like every packaging team in debian, mailing the [EMAIL PROTECTED] > > > or [EMAIL PROTECTED] depending on how old the team is. Usually that > > > list is in the Maintainer or Uploaders field of the control file. > > > #debian-$team is also a good place to look. Those things are > > > _obvious_. > > > > Do you expect potential helpers to search various list archives or > > mail maintainers to ask whether they need help? I would guess only > > no I expect them to contact the teams, and entry points are obvious. > Hiding behind the fact that entry points are not waved under their nose > and that because of that they can't help is, well, Ubuesque. You're missing a couple of points here: 1) That only gets you the help of those that are actively seeking to get involved (and that's a small minority of potential helpers) 2) Those actively seeking to get involved with Debian will tend to look jump in in areas that both interest them AND obviously need help (or at least they'll jump in there first. To give an anecdotal example: I first got actively involved with Debian, because I saw a message asking for translations of the debian-edu install questions, that stated a translation would only take 10-15 minutes. I figured "I can do that", and got more and more involved from there (and I wasn't the only one to help out in reaction to that mail) From what I've observed that's a quite common patern -> asking for help, and taking care where and how to ask, can make a huge difference in the amount of help you receive. > > > Again, I do not appreciate the latent criticism of the big teams to > > > hide their understaff problem. It's blatantly bogus hence iritating, > > > almost insulting. > > > > Don't you wonder why it is perceived like that? > > Yes I do, especially given that in that thread those teams have > claimed many times they need help, and that people continue to pretend > like it never happened. There's been a couple of blogs about the fact that in response to this thread somebody jumped in and started working on antiquated KDE-bugs. -> seems like asking for help had some effect in this case doesn't it? Secondly debian-devel is probably not the best forum for getting help with triaging old bugs why not? Because most people on the list are already heavily involved with Debian, and busy working on their own little problems. So maybe asking for help on debian-kde, where there's people around who might be convinced to pitch in a little time and effort once or twice would be more productive. I'm thinking something along the lines of: Subject: Adopt a bug community drive Hi all, greetings from the KDE-team First for the good news: we're currently managing to keep up with new bugs and quality of the KDE packages is good and improving :) However we have a lot of old antiquated bugs on kdebase that pre-date the formation of the kde-team, and we need your help to clean those up. We'd like each of you to pick out just 1 old bug and help update the information in it (you're of course welcome to do more then 1 :). Mostly this is a question of doing what people on this list are always doing, namely aks the submitter for the necessary information to get at the cause of the bug, and checking if the bug has been reported in the KDE bugzilla, and so on. To make helping even easier here is a step by step instruction on cleaning up old bugs in the Debian BTS: 1) point your browser to the list of kdebase bugs at [1] 2) pick a bug (send a reply to this message on list to avoid multiple people picking the same bug) 3) check the upstream BTS to see if the same bug is reported there, if so ... NOTE: point 2 is opportunity for a bit of bit of social engineering: if everybody in the team picks 1 antiquated bug to follow up on and sends a reply to the list, people will have the impression that something good is happening, mostly the'll go "well, I can do that", and will thus be more likely to jump in. Important points here are: 1) you ask for help 2) you do so in a forum where people are interested in KDE, and a lot of people won't be heaviliy involved yet 3) you point out that helping out does not require special skills or major effort (thus lowering the barrier to entry) 4) you give a step by step instruction of how to get involved (again lowering the barrier to entry) > So Yes I wonder if it's not that it's just easier to pretend it's our > fault Nobody is saying anybody is at fault, which doesn't mean there's no room for improvement. -- Cheers, cobaco (aka Bart Cornelis) pgpWIPSilGjgg.pgp Description: PGP signature
Re: [RFR] po-debconf://am-utils
On Tuesday 06 March 2007, cobaco (aka Bart Cornelis) wrote: AARGH! did it again, sorry all, (me goes of to configure an outgoing filter to prevent doing this again) -- Cheers, cobaco (aka Bart Cornelis) pgpC9lnG7XQuv.pgp Description: PGP signature
[RFR] po-debconf://am-utils
-- Cheers, cobaco (aka Bart Cornelis) am-utils_6.1.5-3_nl.po Description: application/gettext pgpMZditTaZon.pgp Description: PGP signature
Re: [RFR] po-debconf://lam (6 strings)
On Tuesday 06 March 2007, Wouter Verhelst wrote: > On Mon, Mar 05, 2007 at 08:05:08PM +0100, cobaco (aka Bart Cornelis) wrote: > > -- > > Cheers, cobaco (aka Bart Cornelis) > > I think you meant to send this to debian-l10n-nl, rather than -devel :) indeed * me smaks his own head -- Cheers, cobaco (aka Bart Cornelis) pgpLOI5idvz6x.pgp Description: PGP signature
Re: On management
On Monday 05 March 2007, Turbo Fredriksson wrote: > (exept maybe translators, but they don't do it for the project, they do it > for them selfs - which is a GOOD thing! The mere fact that you're able to translate kinda excludes you needing the translation in the first place (e.g. I translate cause I want to make Debian accessible to those whose english isn't good enough, and because I saw a niche to be filled there. On a purely personal level I prefer to run my software in English). There's also people like Clytie (vietnamese translator, very active) who don't even use Debian themselves. So saying translators do it purely, or even mainly, for themselves is doing debian translators in general a disservice IMHO -- Cheers, cobaco (aka Bart Cornelis) pgppUkgFuugFW.pgp Description: PGP signature
[RFR] po-debconf://rkhunter (4 strings)
-- Cheers, cobaco (aka Bart Cornelis) rkhunter_1.2.9-3_nl.po Description: application/gettext pgp2kKqVB7eNX.pgp Description: PGP signature
[RFR] po-debconf://lam (6 strings)
-- Cheers, cobaco (aka Bart Cornelis) lam_7.1.2-1_nl.po Description: application/gettext pgpbmhdoEnZ5U.pgp Description: PGP signature
Re: [RFR] po-debconf://amavisd-new (6 strings)
oops, wrong list should've gone to debian-l10n-dutch -- Cheers, cobaco (aka Bart Cornelis) pgpsfu7t4U5Pj.pgp Description: PGP signature
[RFR] po-debconf://boinc (3 strings)
-- Cheers, cobaco (aka Bart Cornelis) boinc_5.4.11-4_nl.po Description: application/gettext pgp3qHNCj8kw9.pgp Description: PGP signature
[RFR] po-debconf://amavisd-new (6 strings)
-- Cheers, cobaco (aka Bart Cornelis) amavisd-new_1:2.4.2-6.1_nl.po Description: application/gettext pgppErUFqy9Yf.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Saturday 03 March 2007, Theodore Tso wrote: > So I understand where people are coming from when they say that they > want Debian to remain 100% fully volunteer. But first of all, that > isn't even true even now; HP is funding some DD's to work mostly on > Debian-related projects, and certainly some DD's are being paid by > Cannonical, for example. But secondly and more importantly, there > people withour community that have aspirations to be better than what > we can currently offer to our users now, and this includes responding > to bug reports in a timely fashion, and for some people at least, > getting releases out on time and with stable not being quite so > embarassingly out-of-date for quite as long before we can get the next > release of stable out. There's a humongous difference between Debian paying people to work on Debian and 3rd parties like HP paying people to Debian. In particular having Debian paying for labor, moves the decision of who gets payed to work on what into Debian. Doing so brings with it a whole new level of politics. I think we should be very, very carefull before we change the equation that way. -> There's a difference between saying that Debian should remain 100% volunteer, and sayin Debian should not become an employer. -- Cheers, cobaco (aka Bart Cornelis) pgpyrwRlmfZhu.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Thursday 01 March 2007, Pierre Habouzit wrote: > On Thu, Mar 01, 2007 at 03:20:24PM +0100, cobaco (aka Bart Cornelis) wrote: > > On Thursday 01 March 2007, Josselin Mouette wrote: > > > Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit : > > > > > I'm not the one who said maintainers don't admit they need help. > > > > > > > > And I am not the one who said that Mozilla/KDE/GNOME have enough > > > > manpower. > > > > > > Who said that? > > > > > > > Don't put words into my mouth. > > > > > > How about these words: > > > And how do you help a maintainer that does not admit that he > > > needs help? > > > > > > Are they yours, or not? If not, you should consider signing your > > > emails, as someone is trying to fake you on mailing lists. > > > > flaw in your logic: > > > > the quoted part does not say maintainers have enough manpower, > > it only says that they haven't expressed the need for more manpower,or > > at least not in a forum followed by the potential helper. > > No it says that they refuse to acknowledge they need help, which they > did many times. Maybe my english is flawed, but "to not admit sth" > implicates active denial in my understanding. From gcide: Admit \Ad*mit"\, v. t. [imp. & p. p. Admitted; p. pr. & vb. n. Admitting.] [OE. amitten, L. admittere, admissum; ad + mittere to send: cf. F. admettre, OF. admettre, OF. ametre. See Missile.] 4. To concede as true; to acknowledge or assent to, as an allegation which it is impossible to deny; to own or confess; as, the argument or fact is admitted; he admitted his guilt. [1913 Webster] or in other words an admission is an explissive confirmation of a fact. Not giving explissive confirmation (that he knows of) does not imply denial. (it helps if you think of the word in a non-courtroom setting; e.g. a reporter asks if it's true that X, if you reply 'no comment' you've not admitted X is true, but neither have you said X is false) > As a member of such teams, and co-issuer of help requests statements on > user lists (debian-kde@) I did felt quite itched by Eduard statement. I can see how if you read it that way... being an optimist, I choose to always interpret statements in the non-offensive interpretation even when that interpretation is non-obvious. That way I both don't feel offended, and I avoid unnecessary bad feelings when no offense was intended. On the other hand I find that when offense was intended, taking the positive interpretation, really annoys those trying to offend (and doing so without me having to descend to flaming back :) -- Cheers, cobaco (aka Bart Cornelis) pgpXtt2ZYOiot.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Thursday 01 March 2007, Josselin Mouette wrote: > Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit : > > > I'm not the one who said maintainers don't admit they need help. > > > > And I am not the one who said that Mozilla/KDE/GNOME have enough > > manpower. > > Who said that? > > > Don't put words into my mouth. > > How about these words: > And how do you help a maintainer that does not admit that he > needs help? > > Are they yours, or not? If not, you should consider signing your emails, > as someone is trying to fake you on mailing lists. flaw in your logic: the quoted part does not say maintainers have enough manpower, it only says that they haven't expressed the need for more manpower,or at least not in a forum followed by the potential helper. -- Cheers, cobaco (aka Bart Cornelis) pgpQBodoPlXwM.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tuesday 27 February 2007, Pierre Habouzit wrote: > On Tue, Feb 27, 2007 at 11:04:47AM +0100, cobaco (aka Bart Cornelis) wrote: > > On Tuesday 27 February 2007, Josselin Mouette wrote: > > > Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : > > > Who is not acknowledging such obvious things? > > > > People heavily involved with Debian know such things, bug submitters > > that aren't involved (yet) most likely don't. > > > > -> asking them to either pitch in or be patient seems a completely > > sensible thing to do, it decreases frustration, and for some > > percentage of submitters it will be the last little push they need to > > start getting involved > > Ooooh you mean telling all the user base we need help and are > overwhelmed like in [0] or [1] ? > [0] http://lists.debian.org/debian-kde/2006/01/msg00215.html > [1] http://lists.debian.org/debian-gtk-gnome/2006/01/msg00037.html Nope: not every bug submitter reads debian-kde or debian-gtk-gnome, or whatever list is most current for the package in question (in fact i'd say it's more likely that most do not). But let me point out something you seem to have missed (or lost sight of): people are more likely to help you fix a problem if they are directly affected by it (cause people tend to scratch their own itches). -> instead of asking for help on a mailinglist with no direct relation to BTS, it would make more sense to ask bug submitters suffering the effect of the maintainer not having enough time to do sufficient bug triage for either help or patience. > We've seen how good it was for us, at least in the KDE team we got > about ... errr... 0 help offers. you send a mail for help -> good you didn't get any help -> bad but keeping in mind the above, you might want to retarget the request for help? > Could one stop thinking teams packaging large things are as > uncommunicative as some core teams in debian ? Nothing in this thread has said that. The only point this thread makes regarding large packages/package sets is that "large things get more bugs reported, making it harder to keep up, and they also tend to suffer from lots of antiquated bugs from the pre-team erra" Note that's 2 sepperate problems: 1) timely response to new bugs 2) cleanup of antiquated bugs In the case of the KDE team it has in fact been pointed out in this threead that the main problem is 2) and that 1) hasnt't been a problem since the introduction of bts-link. Since this whole discussion is about handling problem 1), it would seem that this discussion isn't pointed at KDE at all ATM, so I'm not sure why you're feeling attacked (or at you least you give that impression). So let me make it explicit: we're not looking to point fingers, we're looking for ways to: a) adress a recurring problem b) get a handle on what the size of the problem is -- Cheers, cobaco (aka Bart Cornelis) pgpa7PMRwoezJ.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tuesday 27 February 2007, Josselin Mouette wrote: > Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit : > > And how do you help a maintainer that does not admit that he needs > > help? > Please show me where a current maintainer of Mozilla, KDE, GNOME, the > glibc, the kernel, X.org or any such big group of packages said he > didn't need help for them. So let's rephrase that: how does a bug submitter the maintainer needs help if that hasn't been communicated in a forum the submitter follows? > YES. WE NEED HELP. NOW. > We are *all* *COMPLETELY UNDERSTAFFED*. > We are drowning in bug reports and are not able to answer all of them, > especially old ones dating from the pre-teams era. > > Who is not acknowledging such obvious things? People heavily involved with Debian know such things, bug submitters that aren't involved (yet) most likely don't. -> asking them to either pitch in or be patient seems a completely sensible thing to do, it decreases frustration, and for some percentage of submitters it will be the last little push they need to start getting involved And as I noted elsewhere in this thread this only needs you to a) keep track of which bug reports aren't being handled (presumably you already have those bugs somewhere low on your todo list, right?) and b) compose 1 mail to that list of bug repports every couple of weeks or so. -- Cheers, cobaco (aka Bart Cornelis) pgpHwZm6eX7UI.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tuesday 27 February 2007, Ben Finney wrote: > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > SO rather than sending excuses-templates, when I've had time to check > > the bug is actually there, I do use the confirmed tag to: > > * ack this is an actual bug ; > > * ack that I've been able to reproduce it (hence implying that I've > > read the report) ; > > * remember that I already read that report. > > For my part, this use of the 'confirmed' tag, which (I believe) gets > sent back to the submitter, is ample feedback that the bug has been > triaged by a real human. I agree completely here, if visible action has been taken there's no need for an ack mail -- Cheers, cobaco (aka Bart Cornelis) pgpIST5DS9QYe.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Tuesday 27 February 2007, Ben Finney wrote: > Ben Finney <[EMAIL PROTECTED]> writes: > > "cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes: > > > - an indication the effort of submitting a bug report is apreciated > > > - an indication the effort will _not_ be ignored in the long run > > > - an indication that actual fixing of the bug will take a while > > > > I think this is significantly more than the OP was proposing. I also > > think that it's unreasonable to expect that *every* bug, no matter > > the severity, should receive this treatment before allowing a new > > version to migrate to testing. > > That should read "... unreasonable to expect that *every* bug, > regardless what severity threshold is chosen, ..." I'm not asking that such a message be sent to every bug, what I'm asking is that: IF you're not going to do anything with a bug for a long period that you send a message to that effect. Note that this basically consists of: 1) gather the list of bugs that are unanswered 2) send 1 short message to that list of bugs In other words 1 mail every week (or 2 weeks) or so. I really don't think that's an unreasonable think to ask (and 1 could possibly be automated by BTS) -- Cheers, cobaco (aka Bart Cornelis) pgpA3LRewQqGe.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Monday 26 February 2007, Don Armstrong wrote: > The goal appears to be to have bugs responded to instantly by > maintainers and fixed rapidly. No, very wrong: - bugs don't need instant response, they need reasonably timely response (say within 2 weeks on average) - BUT, _if_ no triage on the bug is gonna be forthcoming any time soon, I think it's reasonable to at least tell the submitter so, and give some indication as to why. This doesn't have to be more then a few lines (and as a maintainers todo is constant on any given moment it, he can sent the same few lines to all his up-till-now ignored bugs). Would it be hard to add functionallity to the BTS that e-mails the maintainer once every week with a list of bugs for his packages that have been unanswered for 2 weeks or more? If such a mail had the reply-to set to include all those bugs, the maintainer would only have to hit reply and compose a short mail indicating why bug handling doesn't have priority ATM (or that he needs help cause he can't keep up with the influx of bugs). I think composing 1 email each week or so wouldn't be overly much to ask of maintainers, and it would solve the problem nicely IMO -- Cheers, cobaco (aka Bart Cornelis) pgppULUK89t2L.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Monday 26 February 2007, Pierre Habouzit wrote: > On Mon, Feb 26, 2007 at 03:07:20PM +, Stephen Gran wrote: > > This one time, at band camp, Pierre Habouzit said: > > > I was previously beeing ironic, now I'm not anymore. > > > > No, previously you were being sarcastic. There is a difference between > > the two. > > > > I find it quite amusing that you are arguing here that you should not > > have to respond to people reporting bugs to you, when you > > simultaneously argue elsewhere that the uncommunicative nature of some > > teams in Debian is a major problem. > > There is a major difference: I do not refuse help, nor make it almost > impossible for newcomers to contribute. The KDE team is a perfect > example of how new contributors can be integrated smoothly and promptly, > and how easy transition to new maintainers goes when a team is open by > design, and not driven by control freaks. there's a problem with your reasoning here: someone who goes through the trouble of filing a bug report is somebody who'se getting involved in helping the project. Lots of users will just use some other program that does work if they have a problem and not bother filing a bug report. Now granted filing a bug report isn't exactly a major effort, but everybody has to start somewhere, and when people try to help out we should try to make sure it's a positive experience. Having a bug you report silently ignored for long periods is not a positive experience, especially if the bug has a patch (e.g. translations regarly rot in BTS without feedback for months, while the package gets uploads several times [1]). I think we can all agree that this is a desirable _goal_. So the question then becomes wether or not that goal is achievable with the people at hand. So in order to get an overview of the problem I've just created a wiki page [2] could everybody please help fill this in? now sofar in this thread we've identified the following packages/packagegroups having problems: - iceweasel is Eric and Mike (2 people): 528 bugs. - XSF packages is (mostly I think) Julien and David (2 people): I'd say more than 900 bugs (500 on xorg solely). - OOo.org is René (_1_ active people): 459 bugs. - Glibc is mostly done by aurel32, and I try to help (1.5 people): ~300 bugs. - GNOME id 3 active people (2 uploading, 1 doing *only* bug triage), plus 6-7 less active people, for 145 packages totalising 1618 bugs. - evolution with 98 bugs for 2-3 people. - D-I Could people involved with these packages please go to the wiki page and add their projects indicating what their problems are with keeping up with bugs. Right now I've got 2 categories: - can't keep up with new bugs - lots of antiquated still around (I've added KDE in this category as Pierre's earlier mail[3] indicated they're now keaping up with new bugs) Indication of the size of the problem would also be great (as in roughly # antiquated bugs, or roughly #bugs more per week then we can handle) [1] luckily for translators the frequency of this happening has decreased noticably over the last couple of years [2] http://wiki.debian.org/bugSquashing [3] http://lists.debian.org/debian-devel/2007/02/msg00698.html -- Cheers, cobaco (aka Bart Cornelis) pgpmvrwi7qgS4.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Monday 26 February 2007, Sune Vuorela wrote: > On 2007-02-26, Bernhard R. Link <[EMAIL PROTECTED]> wrote: > The bug reports might be read, but not answered. There is no reason to > send a content-less pong to a bug report. there most definately is a point: A user sending a bug report is a user getting involved with the project (in a minor way). Getting involved should be a positive experience, as that encourages more involvment later, which is good for the project. A pong as I proposed elswhere in the thread does 3 things: - it explicitly tells the submitter their effort is apreciated and will _not_ be ignored, though it may take a while to get around to adressing the issue they raised. - it explicitely invites the submitter to get more involved through bug triage or patches (and that little push to get involved might all that's needed, in fact a similar request for translations is how I got drawn in) - it gives some idea of why the bug won't be handled directly (and from that you get a general idea of when it will be handled, or at least when you should ping the maintainer again) All of those are obvious plusses in the big picture view of the project as whole and the relationship of the project with our users. -- Cheers, cobaco (aka Bart Cornelis) pgpoQZw9XEUOB.pgp Description: PGP signature
Re: On maintainers not responding to bugs
> On Mon, Feb 26, 2007 at 01:51:25PM +0100, Loïc Minier wrote: > Instead of forging crappy excuses to say > every time I lack time to do this or that, which is with time, > frustrating and demotivating enough. > > SO rather than sending excuses-templates, it's not an excuse template it's: - an indication the effort of submitting a bug report is apreciated - an indication the effort will _not_ be ignored in the long run -> this has a big impact on the image of the project -> this encourages people to keep getting involved in a simple way (by filing bugs). The resulting positive experience of having gotten involved in Debian in a minor way then increases the chance that people will get involved in other -more involved- ways later, and bug triage might very well be 1 of those ways. Doubly so if your template mail asks for help with bug triage. (Aside this is actually exactly how I got involved with translation, I reported a problem and got a pointer on how to help, I branched out from there) I think we've all been in situations where we switched from software A to software B because project A ignored (or seemed to ignore) our bug reports and/or patches? Now ask yourself which project your more likely to get actively involved in: the one giving feedback, or the one that seems to ignore you? - an indication that actual fixing of the bug will take a while -> this avoids avoids unrealistic expectations on the bug reporters part -> this avoids bug reporters bugging the maintainer every couple of days/weeks/whatever with "hey what's going on" (with asociated mounting frustration on both sides) > And hell no I won't send "standard" mails to submitters, I hate to > receive such mails, I won't send such. I like to receive mail when there > is useful information. When I submit a bug, I know there is one, so the > "ack there is a bug" mail is somehow ... polluting my mailbox. the point is not acknowledging the existence of the bug, it's acknowledging the effort of the submitter and expressing an appreciation for it. This both increases the chance the submitter will get more involved in the future, and decreases the amount of frustration. (NOTE: we're mainly talking about bugs that rot in BTS for months or longer, so' it's not about sending such a mail for _every_ bug, just for those bugs you know you're not gonna get around to any time soon) > Though, in this discussion we're talking a lot about the past. Quite to the contrary, see below... > For KDE, we (I say we as a habit, but I'm not really in the team > anymore...) struggle with the old antiquated bugs a lot dealing with antiquated bugs already in bts is another problem entirely as in that case the bad experience (for the bug reporter) has already been had, and the damage's been done. Having such an old bug closed is great, but I suspect that in many cases the bug submitter will have given up and moved on anyways. -> we're not talking about cleaning up old messes but avoiding new ones > but I think we're able to keep up with new bugs since bts-link exists. and this would indicate the KDE team is succeeding in doing that now, which is great :) > bts-link improved our workflow a lot, because now, when a new bug > arrives, then you need to check its validity, and if it's verry annoying > or not. If it's not a major blocker, then you forward it upstream, and > mark the bug as forwarded. The improvement, is that thanks to bts-link, > we then can forget about that bug completely, as we will be notified > when upstreams made progress on this. > > Obviously, for many reasons, the submitter is not really notified > about what is going on, but: > * looking at the BTS he can in one click read the upstream bug log, > and follow-up there if neede ; as long as the sumbitter knows Debian maintainer has forwarded it upstream this is not a problem (for Debian), because at that point any frustration about non-responsiveness will be pointed at the upstream project and not the Debian maintainer and Debian. > I quite choke on his words, because I really > think KDE packaging workflow has never been better in the last 3 years. > It does not mean it can't be even better, but we're definitely working in > the good direction, and are not slugged either. happy user of kde packages myself, and I definately agree that things have improved enourmously the last several years, so let me take the opportunity to give you guys a heartfelt thanks :) -- Cheers, cobaco (aka Bart Cornelis) pgpMQOtRwFDOq.pgp Description: PGP signature
Re: On maintainers not responding to bugs
On Monday 26 February 2007, Marco d'Itri wrote: > On Feb 26, Ben Finney <[EMAIL PROTECTED]> wrote: > > "You and others" cannot substitute for a response *from the package > > maintainer* acknowledging (or otherwise) the bug report. That's the > > criterion being discussed here: not a resolution for the reported bug, > > but rather a first response from the package maintainer to the bug > > report, to acknowledge that it has not been ignored. > > If a maintainer keeps doing uploads we can be almost sure that he is not > "ignoring" bugs too. no we can't, as an example I had a bugrapport (with patch) open on desktop-base for over a year, no reply. It came up in discussion at debian-desktop list and turns out the maintainer list had somehow gotten unsubscribed from the package bugs, and the maintainer simply hadn't seen the bug. > Providing an useful answer to a bug requires proper bug triage, which > requires time. Just an ack, would alleviate frustration on the users' part enourmously. I'm thinking of something like the following: I've seen your bug report, at first glance fixing it seems to have lower priority then A, B, and C on my TODO-list. So please be patient, I will get around to it eventually. If you want to help speed things up by helping with bug triage or patches that would be both welcome and very much apreciated. Note that the point of such a standard answer mail is not to get the bug fixed faster, instead the point is to: 1) you don't want to leave people hanging (as an exercise in understanding the users point of view pretend it's an ftpmaster or other central project function that isn't showing any visible reaction to whatever information/action request you send) 2) it might prompt the bug reporter or somebody else noticing this to jump in and help out. Also note this doesn't have to take long. Basically: 1) check if the bug is _obviously_ major enought to have to be dealt with immediately. (you do that already right?) 2) if not send your standard reply, asking users to either be patient or help out -- Cheers, cobaco (aka Bart Cornelis) pgpLFwLqOHUrK.pgp Description: PGP signature
Re: Bugs in default GNOME etch?
On Monday 22 January 2007 18:05, Josselin Mouette wrote: > Le lundi 22 janvier 2007 à 16:44 +0100, cobaco (aka Bart Cornelis) a > écrit : > > Those capplets were wanted enough to have been made, so obviously they > > scratch someones itch. Or in other words they're usefull to someone > > even if they're not usefull to you personally. > > Oh, really? > > Do you often need to call gstreamer-properties? This is the perfect > example of a useless feature. Me? nope, but then I'm not an audiophile, and I'm guessing they both want and need that kind of control often. This is the whole point: ONE SIZE DOES NOT FIT ALL > if the capplet should probably remain available from the command line, it > shouldn't remain in the menu. Right, cause gnome is a graphical environment, so by all means lets rip out the graphical way of doing things, who needs anything but a command line anyway... How about a more sensible approach, like oh say: have it configurable which capplets are shown in the menu, with a sensible default list not showing any of the 'insane' ones? But I guess that's not the gnome way, cause that would mean another useless configuration option, much faster and easier to just rip it out instead. > Do you really think nautilus-file-management-properties is needed in the > menu? These are settings specific to nautilus navigation, and they are > available from every open nautilus window. Surely you'd expect nautilus > settings to be available from the panel and not in nautilus... At first glance this would seem to be a clear case where consolidation is both in order and obvious. I don't see any removed features in this case (but then I'm not all that familiar with either, as I don't use nautilus personal, hence the 'at first glance'). But then does it hurt to have the option to show it in a capplet in the menu? (Note that 'option', it doesn't necessarily have to be on by default) > > The above paragraph only succeeds in reinforcing my believe that the > > gnome usability engineers cut and ran instead of adressing the actual > > scaling problem. And the above seems to indicate gnome's all set on > > doing it all over again. I'm gonna guess that was not the picture you > > were trying to give? > > Take the pictures you want. I'm not a photographer. Sure, I'm just another (ex-)gnome user right? What I was trying to point out is this: 1) the gnome approach to usability has a serious image problem and created a huge user backlash (disgrunteld ex-gnome users abound) 2) your points here have _not_ helped mend that image, quite the contrary, you've only reinforced it Now if that's what you set out to do, then great. If not you might want to reconsider your approach in the future. -- Cheers, cobaco (aka Bart Cornelis) pgpKzFuFv0ike.pgp Description: PGP signature
Re: Bugs in default GNOME etch?
On Monday 22 January 2007 15:08, Josselin Mouette wrote: > While it is completely useless bloat for capplets (or at least, it would > if capplets were merged appropriately and useless ones were removed), I > hope it will be used for panel applets insertion. Those capplets were wanted enough to have been made, so obviously they scratch someones itch. Or in other words they're usefull to someone even if they're not usefull to you personally. Besides didn't you imply earlier ([1],[2]) that gnome was consolidating features, not removing them? So Which is it? The above paragraph only succeeds in reinforcing my believe that the gnome usability engineers cut and ran instead of adressing the actual scaling problem. And the above seems to indicate gnome's all set on doing it all over again. I'm gonna guess that was not the picture you were trying to give? By all means merge the ones that can be merged, but do everyone a favor and do _not_ remove the remaining ones even if you consider them useless: if someone went trough all the trouble of creating it and getting it included it's obviously usefull to someone. [1] http://lists.debian.org/debian-devel/2007/01/msg00626.html [2] http://lists.debian.org/debian-devel/2007/01/msg00643.html -- Cheers, cobaco (aka Bart Cornelis) pgpvnr5GtfSjb.pgp Description: PGP signature
Re: Bugs in default GNOME etch?
On Saturday 20 January 2007 14:21, Josselin Mouette wrote: > Le samedi 20 janvier 2007 à 13:34 +0100, cobaco (aka Bart Cornelis) a > > IMHO that just means those usability engineers took the easy way out of > > a scaling problem: instead of adressing the actual problem, they just > > made sure they didn't have to deal with it. > > Why do you assume it? The usability processes in GNOME imply, on the > contrary, that there is a good way to achieve every use case. > Improving usability often means replacing two non-optimal ways of doing > something by a single, better way of doing it. no disagreement here, provided that's possible, it often isn't > You only see the two things removed, through the deforming glasses of the > rumor, and miss the overall usability improvement. So Gnome has obviously not 'removed tons of features' (your words), they've instead consolidated features, replacing multiple features with single better features all over the place? And I suppose the mountains of rants and complaints on the subject are all from (power) users that failed to find the new consolidated features, right? Off course: - if so you have a usability problem (as clearly indicated by lots of power users not finding the consolidated features) - if not, my point stands -- Cheers, cobaco (aka Bart Cornelis) pgpgzfr5ODkgZ.pgp Description: PGP signature
Re: Bugs in default GNOME etch?
On Saturday 20 January 2007 11:51, Josselin Mouette wrote: > Le samedi 20 janvier 2007 à 04:30 -0500, Greg Folkert a écrit : > > I would assert they are not listening to their former BIGGEST fans and > > users. You can easily find droves rants/discussions of current GNOME > > users very disgruntled with the REMOVAL of features that previously > > were there. Some users are now FORMER GNOME users due to these > > removals. > > Features. Features, features, features. Do you only want features, > without even knowing whether they are useful? Sorry, usability is not > about features. Wikipedia defines usability as : Usability is a term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal. ISO 9241-11 (1998) Guidance on Usability, defines usability as: The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. By taking out features you decrease the number of goals you can use the software for. If you can't use the software for a certain goal at all then it's less usable for that goal then a package with an interface from hell that does let you addres that goal. => by definition taking out (lots of) features decreases the maximum usability of the software. > I, for one, thank those usability engineers for removing these tons of > useless features that clutter menus, desktop, applications, and dialog > boxes. IMHO that just means those usability engineers took the easy way out of a scaling problem: instead of adressing the actual problem, they just made sure they didn't have to deal with it. Yes, organizing lots of features so all them are easy to use is a very hard problem. BUT those fabled usabillity engineers not only turned tail and ran, they mobbed everyone who dared to point they did. As far as I'm conserned the emperor isn't waring any clothes. > You can gain much productivity by removing them, and that doesn't > only account for newbie users. Every one of those features came to be because it scratched someones itch, judging by the amount of rants and complaints I've seen about those removed features those itches still need scratching. Thus Gnome has actively stopped a whole slew of users from scratching their itches the way they did before. IMHO that's monementally stupid. -- Cheers, cobaco (aka Bart Cornelis) pgpglEi5U38wz.pgp Description: PGP signature
Re: Why not making /sbin/sendmail a mantadory component for mail operation?
On Wednesday 17 May 2006 23:08, Roberto C. Sanchez wrote: > Lionel Elie Mamane wrote: > > On Wed, May 17, 2006 at 09:42:42AM -0300, Henrique de Moraes Holschuh wrote: > >>An open outgoing port 25 is commonly blocked by default anywhere you > >>have non-incompetent network management, unless you are on the > >>business of selling full internet uplinks for server hosting, or you > >>do business with spammers. > > > > Or unless you want ... customers. > > Except that most customers don't know what a port is, nor much less care > that any are blocked (unless it prevents them from playing everquest or > chatting). Most people don't run their own mail servers and can easily > be convinced by the ISP to use a mail client like Lookout, which is > pointed at the ISP's outbound mail server. Personally, I think it is a > responsible thing for mass market ISPs to do. recommending the most virus-infected piece of mail-software around is a responsible thing to do? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpF2qwrwqQfv.pgp Description: PGP signature
Re: Creation of custom "configured" packages?
On Wednesday 17 May 2006 08:33, Marc Haber wrote: > On Tue, 16 May 2006 15:09:37 +0200, "cobaco (aka Bart Cornelis)" > > <[EMAIL PROTECTED]> wrote: > >How so? As an admin you can always comment out any conf.d file > > completely if you don't want what is in there. After which dpkg will > > come with the usual prompt at package upgrade about the conf-file being > > changed allowing you to keep it that way without any effort. > > Aren't we talking about delivering local configuration to a system > with an independent package? That package cannot comment out a conf.d > file that comes with the original package. right, got you now: there's 2 viewpoints: - that of the local admin (the 'delete configuration' you mentioned made me assume you were talking about the local admin viewpoint, my bad) -> can always override everything wether it's monolitic or modular -> modular is better if the admin just want to set some additional options (you don't need to mess with the conffile in the package, so you don't get the "conffile has changed" prompt on upgrade because you set a couple of extra options) - that of another package -> modular _at_least allows to add bits of configuration which is usefull for: - plugins offering extra functionality - things building on another service (e.g. web-applications) - configuration packages of CDD's -> _might_ allow overriding of configuration *IF* the config system always uses either the first or last value encountered for a particular setting and looks at things in some non-random order. Which I'm guessing should moslty be the case, and is at least sometimes be the case (e.g. the modularized system-wide on-login scripts for those shells that have them) => /etc/.d directory might not be perfect, but it's good sight better then monolitic configuration files -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpOUZPsogPyr.pgp Description: PGP signature
Re: Creation of custom "configured" packages?
On Tuesday 16 May 2006 12:10, Marc Haber wrote: > On Tue, 16 May 2006 10:28:57 +0200, "cobaco (aka Bart Cornelis)" > > <[EMAIL PROTECTED]> wrote: > >1) use multilevel/modular config where available: > > usually in the form of a /etcc/.d directory > > (e.g. /etc/apt/conf.d), or stacked config sets (e.g. the major > > desktop environments, see desktop-profiles package) > > conf.d directories are problematic when one wants to delete > configuration pre-delivered by the Debian package. How so? As an admin you can always comment out any conf.d file completely if you don't want what is in there. After which dpkg will come with the usual prompt at package upgrade about the conf-file being changed allowing you to keep it that way without any effort. How is this significantly different from any other configuration provided by packages? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp7zysTuFKEG.pgp Description: PGP signature
Re: Creation of custom "configured" packages?
On Monday 15 May 2006 09:49, [EMAIL PROTECTED] wrote: > Hi, > > in case I am in the wrong list, I beg you pardon, but I asked this > already in debian-user without success. > > I would like to build customized, configured packages (for example > additional bash script for the bash package, some default keybindings > for screen, some host in /etc/ssh/known_hosts for ssh ... the list is > endless), because maitainigs multiple systems becomes frustrating > otherwise, if you maintain more than 2 computers (4 in my case). > > What would be the best (cleanest, most debian-like solution) be? I > thought of "meta-packages" with pre-depends to the real packages and > dpkg-divertions for the config files? you've just run into the main problem of CDD's (hence debian-custom would also be a good place to ask for help) > Are there other possibilities? usual approaches are as follows (in order of preference): 1) use multilevel/modular config where available: usually in the form of a /etcc/.d directory (e.g. /etc/apt/conf.d), or stacked config sets (e.g. the major desktop environments, see desktop-profiles package) 2) use debconf preseeding: con: only works before initial installation of whatever package of which you want to customize the configuration 3) use cfengine (or something similar) to customize the configuration: con: can't be automated in a policy compliant manner (though that's likely not a problem for your own use) long-term Debian solution is pushing for 1) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpph6AaoTFs3.pgp Description: PGP signature
Re: Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)
On Wednesday 03 May 2006 22:56, Bill Allombert wrote: > On Thu, Apr 27, 2006 at 12:53:01PM +0200, cobaco (aka Bart Cornelis) wrote: > > On Sunday 23 April 2006 20:26, Russ Allbery wrote: > > > Jari Aalto <[EMAIL PROTECTED]> writes: > > > > What we need and what should have been done a long time ago, is to > > > > modularize profile to /etc/profile.d/ where each program is > > > > resposible for shipping reasonable defaults. Redhad has done this > > > > long time and Cygwin does that too and it works very well. > > I suggest the post below that detail how they use it and why > this is not needed in Debian: > > <http://lists.debian.org/debian-policy/2004/06/msg00136.html> I'll take the various arguments in that mail and give my take on it (correct me if I misinterpreted anything): Debian shells are not required to be POSIX compliant, only /bin/sh. In practice, I expect you will have a hard time to write shell scripts that are valid for both tcsh and bash. /etc/profile is only used by bourne-compatible shells (of which tcsh isn't one). Most things can be writte in a way that's valid for all bourne-compatible shells, and any bits that can't can easily be wrapped in an appropriate if-statement I would like to point out that the correct way in Debian to set environnement variable for all users is to use /etc/environnement. while very true, this is not a valid objection: - there's no way to conditionally set variables through /etc/environment. Sometimes you want to influence things through environment variables based on run-time tests (see for example my desktop-profiles package which does exatly that in order to fix a corner-case bug for those shells that allow it) - configuration packages are another valid use case (see below) One approach will never fit everyone: where one person sees bloat another sees service. (I think we can all agree on that?). In light of that it makes sense to offer a mechanism through which people can pick and choose the level of service/bloat they want. Which is exactly what modularizing /etc/profile would allow (through configuration packages that implement a particular level of service/bloat). NOTE: this does not get in the way of base-files only offering a minimal level of bloat/service. As for the whole part of the mail critizing the redhat bloat, it's irrelevant if somebody wants to provide a configuration package implementing the exact set of bloat/service offered by redhat then that's fine. Only those users that want it will install it. > In that case, I would suggest to introduce a /etc/bashrc.d and > /etc/kshrc.d rather than a /etc/profile.d. Why split it per bourne-shell-variant? - Most things can be put in a way that's valid for all bourne-compatible shells (i.e. those using /etc/profile). - Those few bits that are specic to 1 shell-variant can easily be surrounded by an appropriate if-statement as the start of this bug illustrates. -- Cheers, cobaco (aka Bart Cornelis) pgpZokFWFaOiC.pgp Description: PGP signature
Re: Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)
http://lists.debian.org/debian-custom/2005/05/msg00014.html has S has Sergio's summary of the devcamp meeting [2] for the same reason that desktop-profiles needs it, not unlogical as the latter is a generalization of the approach used by debian-edu-config to customize the KDE-configuration, plans are to migrate debian-edu-config to desktop-profiles for the etch version of debian-edu. -- Cheers, cobaco (aka Bart Cornelis): pgpJ0FOaXLF9B.pgp Description: PGP signature
Re: dicussion about patches ... ignoring patches make motivation toprovide them fall
On Tuesday 21 March 2006 20:43, Thomas Bushnell BSG wrote: > Nathanael Nerode <[EMAIL PROTECTED]> writes: > So a mere non-reply does not, it seems to me, connote anything bad; it > may simply mean that the bug report is complete in itself, and well > get attention when I decide I have the attention to give it. If more > than this is required, more needs to be asked. The problem with that is that there is no way for the submitter to know that, there's several possible reasons for not getting any reaction: - maintainer currently busy with other stuff - maintainer MIA - maintainer doesn't care - maintainer thinks bugrepport is complete and doesn't need any more info, will be included/fixed in next upload - ... By not answering there's no way for the submitter to know which of the above applies, it's an issue of not leaving users in uncertainty about what is going on. A simple 1 line reply is enough to remove that uncertainty: - this takes maybe half a minute - this makes Debian look a _lot_ more responsive then 2 months of silence wile notting happens (because the maintainer is working on more pressing problems/other packages or whatever). -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpKx2KczbsPW.pgp Description: PGP signature
Re: [ad-hominem construct deleted]
On Wednesday 18 January 2006 21:51, Matt Zimmerman wrote: > On Wed, Jan 18, 2006 at 09:41:58AM +0100, cobaco (aka Bart Cornelis) wrote: > > syncinc _to_ debian implies that changes are _pushed_ to Debian > > regularly, whereas in actuallity they're simply made available for pull > > by Debian (in most cases) > > I am pleased to report to all who were confused or offended by the > ambiguities in these quotations that Mark has clarified them both in the > wiki already. :-) > > Considere the following: > > - right now there are no Ubuntu changes to my package > > - if Ubuntu suddenly does change my package for whatever reason, > > there's absolutely no way I'll suddenly know to go check the patch > > page. > > The PTS already contains this information; if you want asynchronous > notification, that should be easy to arrange within the PTS. right, that solves part of it. BUT this still doesn't help with the having multiple logical changes (most of which might not apply) in a single patch (an example of which was detailed earlier in this subthread) Problems I have with this: - I don't know of any upstream that accepts patches like the one discussed. Let along does so routinely. So why is Debian expected to be different in this regard? - After having looked over a new patch with the same/similar non-applicable changes a couple of times, and no (new) applicable changes people will, quite rightly IMHO, stop looking at the linked ubuntu patches, which is surely not what Ubuntu wants? (from comments I've seen in blogs and other places, this is definately a major source of frustration on the side of DD's). Providing 1 patch per logical change should be possible, assuming each logical change is made seperately. (Which should be the case most of the time I expect?) Has Ubuntu looked into this? If so what were the problems keeping this from happening? Is it completely impractical, is it being worked on, or ... ? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpk5tGMUro5T.pgp Description: PGP signature
Re: [ad-hominem construct deleted]
this patch for Debian yet. > > - Packaging transition for the gcc4 C++ ABI. Debian developers were > notified about the availability of these patches in Ubuntu when the > transition began in Debian, though it looks like you chose not to > use it, and rebuilt the package instead. > > - autoconf has been re-run. > > In other words, I don't see what it is that you're dissatisfied about, in > your role as maintainer of these packages. Are you speaking for yourself > or on behalf of someone else? So here we have Ubuntu offering a monolitic patch with 3 seperate logical changes. One of which you yourself identify as 'not-for-Debian', a second which should probably be classed that way also, and in any case has no bussiness being mixed in with the gcc4 C++ ABI change patch. Do you know of any upstream at all that would be satisfied with routinely getting patches this way? Let alone accept them? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpPGDrQ6Jwom.pgp Description: PGP signature
Re: Need for launchpad
On Friday 13 January 2006 16:27, Thomas Hood wrote: > John Hasler wrote: > > I can't see how putting up patches on a Web site is better than > > (or even as good as) filing bug reports. > > The web site requires less labor to maintain than hundreds of bug > reports. for Ubuntu that's true, for the Debian maintainer it's not > However, if a particular Debian Developer > feels motivated to improve his package then he'd be well advised to > examine what Ubuntu has done to it. I've seen comments from maintainers that tried this and stopped doing so because it turned out to be more work then (re)doing things themself. The number of such comments I've come acrosss would lead me to believe that at the very least the ubuntu patch publishing needs (significant) work to be usefull in the majority of cases. So at the moment I'd say the above statement is false. > Transfer of information requires two parties: a provider and a recipient. > Ubuntu, the provider, has published its changes. The transfer can only > be completed when the receiver is ready to receive, but this is not > always the condition of Debian maintainers. > So it is efficient if the transfer take place on the initiative of the > latter. Once he or she is ready, he or she doesn't have to "hunt", because the patches are all at a known location. as documented experience by maintainers who've tried that shows, this is inefficient enough that reimplementing is mostly faster (and definately more attractive, as it involves less drudgework) -> ubuntu needs to improve efficiency _for_debian_maintainers_ if it wants them to use their patches (if it doesn't that's fine, though not ideal, from a Debian perspective) > > Ah, here we come to the heart of the problem: "when they have been > > approached", this clearly points to the fact that the initiative > > for synchronization between ubuntu and debian lies with Debian not > > Ubuntu (by and large, some exceptions have been mentioned). > > Right. > > > In the mean while Ubuntu proudly calls "ubuntu gives things back", > > whereas in reality we mostly have a situation of "ubuntu will help > > debian maintainers that want to take things back" > > I don't see a profound difference between "helping to take" and "giving". > Perhaps what you want is "giving on a silver platter"? the difference is the one between push and pull, i.e. were the initiative lies. And Ubuntu is claiming it's pushing things where it's not. -> Ubuntu not pushing things is just ducky in itself. -> Ubuntu doing so while sayingthey are is _not_ okay (and that's the impression a lot DD's seem to have right now) > > -> It's this misrepresentation of where (most of) the initiative lies > > which pisses people off. > > I think that people are pissed off for other reasons. (But I admit > that I can only speculate. I can't read people's hearts and minds.) > > Suppose Ubuntu were to cease claiming[0] that it gives back to Debian. > Would everyone be happy then? I'm pretty sure people would be happier with one of the following: - Ubuntu actually doing what it's claiming (i.e. pushing changes to debian) - Ubuntu stop the claiming take your pick. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpevJbtDV4zh.pgp Description: PGP signature
Re: Need for launchpad
On Friday 13 January 2006 12:04, Thomas Hood wrote: > I agree that it would be nice if Ubuntu developers tried to get their > changes into sid. It is certainly not their responsibility to do so, It isn't? Presumably they're that ones that want to remain close to Debian (as any divergence means more work for them?)? So how is it the Debian maintainers responsibility to go hunting for usefull patches? Debian maintainers for the most part would love to not have to duplicate work already done by Ubuntu. But at the moment I've seen lots of comments by maintainers saying that in most cases it's currently more work to find out if there's any usefull bits in the diffs between debian-ubuntu packages, then to do the work themselves (for various reasons, which have been mentioned before) > but in my experience Ubuntu developers have been very cooperative when > they have been approached. So I don't see a big problem. Ah, here we come to the heart of the problem: "when they have been approached", this clearly points to the fact that the initiative for synchronization between ubuntu and debian lies with Debian not Ubuntu (by and large, some exceptions have been mentioned). In the mean while Ubuntu proudly calls "ubuntu gives things back", whereas in reality we mostly have a situation of "ubuntu will help debian maintainers that want to take things back" -> It's this misrepresentation of where (most of) the initiative lies which pisses people off. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp0THzWMuhMm.pgp Description: PGP signature
Re: Conffiles and possible conffiles
On Monday 21 November 2005 16:44, Goswin von Brederlow wrote: > Frank Küster <[EMAIL PROTECTED]> writes: > > Hi, > > > > on the debian-tetex-maint mailing list we often have problems to decide > > which of the thousands of TeX input files should be treated as > > configuration files - in principle, each of them can be changed in > > order to change the behavior of the system. We are currently thinking > > about a solution were there would be hardly any conffiles[1], but a > > local admin could put copies of any file he likes into subdirectories > > of /etc/texmf. This would shadow the dpkg-shipped file in > > /usr/share/texmf and allow configuration. And of course we would > > document this. > > > > > > What do others think? Would it be acceptable Policy-wise to handle > > configuration like this? > > > > Regards, Frank > > I think other packages have the same problem, gconf comes to mind, and > they should sit together and work out a common solution. Multi-level configuration is definately the way to go when possible IMHO (this was also the conclusion reached at the CDD devcamp last spring). gconf/gnome, KDE, XFCE, and any freedesktop-basedir-spec compliant system already allow multilevel configuration stacking: each has a search path which specifies the locations to look for any config key, for each config key the search path is looked through and the first match is used (the desktop-profiles package provides a general mechanism for managing the search paths of the various DE's) So you can for example have 4 config sets (each in its own location): - one with the upstream default values - one with overrides for upstream settings by maintainer - one with cdd-overrides for the settings - one with admin-overrides for the settings Each party can then change his settings independently of the others, overriding (only) the defaults they care about. > > There is one major drawback, however: If a file that has a (changed) > > copy in /etc/texmf is changed in the deb, the user gets no > > notification. This is at least annoying - but on the other hand, many > > users have newer or changed versions in /usr/local/share/texmf or in > > $HOME/texmf, and they face the same problem. > It would be nice to notify the user about changes in the default > config and give the choice of a diff or 3 way merge. Maybe this is > something that could be added to ucf (e.g. option > --modified-file=/etc/texmf/foo) and then present the user with the > same options and frontend as with normal config files. If (as is the case for KDE, Gnome and XFCE) the granularity when combinying the different configuration settings is per config-key and not config-file any merge problems basically disappear: you just make sure you set the search path to reflect the precedence among the various configuration sets, any changes made by a party whose configuration settings have lower precedence are then used transparently unless you've overriden that specific setting. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpK7UVOT8ijI.pgp Description: PGP signature
Re: Bits from the release team: the plans for etch
On Wednesday 26 October 2005 23:38, Stephen Gran wrote: > While I appreciate the effort at a standard shell script fragment for > 'install a user', and think that it would be useful as reference and for > reuse, I tend to think making it a dh_ fragment doesn't work in the > normal use cases I can think of. Ordinarily, when a package installs a > user, the logic of the maintainer script goes something like: > > add user > > chown a bunch of stuff to the new user > > start the daemon If chowning a bunch of stuff is the only thing most package installs do couldn't you just add a file with a list of things to chown for the dh_user command to use? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp1hhjWhD3EC.pgp Description: PGP signature
Re: And now for something completely different... etch!
On 2005-06-07 04:57, Grzegorz B. Prokopski wrote: > On Tue, 2005-07-06 at 01:03 +0200, Javier Fernández-Sanguino Peña wrote: > > - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, > > 4=5 > > Do we really need that? I thought I could always > enable/disable/install/remove [xgk]dm. And are these runlevels mandated > (or at least documented) by any standard (besides 'the RH way')? Are > they at least consistent among ~"all distros besides Debian"? If we're gonna change this, could we please use the LSB definition [1]? [1] http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/runlevels.html -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam)
Re: Is Ubuntu a debian derivative or is it a fork?
On Wednesday 01 June 2005 07:06, John Goerzen wrote: > On Tue, May 31, 2005 at 07:47:19PM -0700, Matt Zimmerman wrote: > > On Tue, May 31, 2005 at 09:00:33PM -0500, John Goerzen wrote: > I'm aware of that. There are cases, though, where people tend to > create a difference when it's not necessary. A common place is graphics > on the default desktop. I don't know if Ubuntu changes those, but I know some derivatives do, > and thus have to fork some packages. I figure it would be easier to > use /etc/alternatives to manage those defaults, but that's just me. does not follow, it's unnecesary to fork packages in order to change the default desktop setup (and has been for forever): - you can always add a configuration-set by putting it in a directory, and adding that to the search path variable for your DE (note: for gnome you need to adjust the gconf path file instead) - desktop-profiles now provides a standard way to set up extra configuration-sets, allowing the admin to control the activation of them in 1 place regardless of the DE used (but even before that you could always set the environment variable in , skolelinux does) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp9POFMGqqoY.pgp Description: PGP signature
Re: my thoughts on the Vancouver Prospectus
On Sunday 20 March 2005 16:16, Anthony Towns wrote: > Sven Luther wrote: > > [...] and they hold us hostage [...] > > Friendly, > > It seems odd to pretend to be friendly towards people you consider > hostage takers. Or to call people you claim to be friendly towards > "hostage takers". it's called 'Stockholm Syndrome' and it's a well documented and common ( in such circomstances) physological phenomenon SCNR -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpudpPCOIRBA.pgp Description: PGP signature
Re: A new arch support proposal, hopefully consensual (?)
On Sunday 20 March 2005 16:59, Thomas Viehmann wrote: > Sven Luther wrote: > > 7) the porter team has the possibility to providing arch-specific > > overrides to solve the issue of a package not passing from unstable > > into testing due to a tier1-specific RC bug or whatever. Should be used > > sparingly though. > > This seems problematic in this respect. > > I might have missed the previous suggestions or the obvious flaws of the > idea, but why not have something along the lines of "releasing all > 'tier2' arches with the packages they have", i.e. agressive per-arch > removal for uninstallable/unusable/not-up-to-date packages. Those arches > that have something worth releasing at release time (installer, all > priority >= important, x% of optional in usual release quality) do that. > This way, the security support of the additional arches would stay > largely the same. > One could have the present testing rules up to some > point and switch to "if arch-specific RC bugs/testing delays pop up, > stuff get removed" for release. I like this idea, any cons? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp4iyBiruyDm.pgp Description: PGP signature
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tuesday 15 March 2005 22:42, Brian Nelson wrote: > On Tue, Mar 15, 2005 at 10:26:58PM +0100, Ola Lundqvist wrote: > > Hello > > > > As most people in this threas have expressed lot of bad feelings about > > this. I must tell that I think this proposal is a good step toward > > quicker releases etc. > > > > With the clarifications (see the new thread) I must say that this > > is a very sane proposal. > > > > Some people tend to think the worst of everything. If you look at this > > proposal as a proposal and with the intention to make things working > > in a good way, I think this proposal is one of the best ones in a > > very long time. > > I agree. It's become quite evident that Debian is barely able to make > releases at all with the status quo. what status quo? We went from: - 1 RM to a release team - lots of kernel source package to 1 kernel source package (per kernel-version) - kernel being maintained by lone maintainer to kernel being maintained by team - unmaintanable installer that nobody wanted to work on, to great new installer with lots of people working on it - we updated some of the infrastructre were that was necessary All of these are considerable improvements, that should I think help us make new releases easier, things are improving > And, given a choice between having > no stable releases at all and having stable releases of a significantly > reduced number of arches, I'd gladly choose the latter. Do we have scalability problems -> yes Is it clear that those problems are fundamentally unsolvable (and hence we'd need to limit the number of architectures) -> not at all > What baffles me is why so many seem to miss this point and instead have > decided to turn it into a religious flame war. we haven't missed the point: - namely we need to release in a somewhat predictable time frame (only releasing once every 2, (or even 3) years is not the main problem, the problem is that we spend over a year saying we'll release RSN and ) -> lots of people just disagree that with how the Vancouver proposal goes about solving the problem -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpE1suGU0BZz.pgp Description: PGP signature
Re: Questions for the DPL candidates
On Tuesday 15 March 2005 02:50, Anthony Towns wrote: > cobaco (aka Bart Cornelis) wrote: > >>That's why it's posted on the lists now -- it never too late to get > >>input into something in Debian; even after we've committed to > >> something, we can almost always change our minds. > > > > er, saying "we've committed to this" really comes across as a 'fait a > > compli' to a lot of people. > > Any "proposal" made by all the people who'll have to implement it is > going to come across as a fait accompli, no matter how you phrase it. > And, to some extent, that's exactly the right reaction. from the discussion going on in this thread I gathered that neither the porters, nor the security team, nor the kernel team was present in Vancouver, I would definately class them as part of "people who'll have to implement this" > But, I mean, take the above -- I didn't say we'd committed to this; I > said that if we had, it could *still* be changed -- yet your instinct > was to take the opposite implication out of it. right, as other people have mentioned, this proposal was phrased in pretty much the worst way possible, that does not help getting the right reaction > > again I'm missing why's here, it may be obvious to members of the > > release team, but it's not obvious to me (nor it would seem a lot of > > other people on the list), and an "I think" does not tell me anything. > > There're a range of reasons, most of which probably won't be obvious to > everyone 'til after the fact. which is why I would expect whoever makes the proposal to explain the reasons. > Having more flexibility to bend the release requirements, and > being able to choose to focus porting efforts on a stable target instead > of a moving one are useful features for some ports, though, I think. doesn't the Vancouver proposal say that tier-2 architectures would be based on unstable? I'd hardly call that a stable target. As proposed elsewhere in the thread testing would be better if that's the goal. > > if you want a technical discussion intead of a political one it helps > > to > > ...not have it on a Debian mailing list. :-/ ok, while you do have a point (to some extend), explaining things would at least cut down on the peripheral stuff considerably. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpYHJGSOE9ov.pgp Description: PGP signature
Re: Questions for the DPL candidates
On Monday 14 March 2005 23:35, Anthony Towns wrote: > Matthew Garrett wrote: > > Steve Langasek <[EMAIL PROTECTED]> wrote: > >> Andreas Schuldei (DPL candidate) > >> Angus Lees (DPL candidate) > >> Branden Robinson (DPL candidate) > >> Jonathan Walther (DPL candidate) > > > > Little advance public warning was given about this meeting, and the > > scope of the discussions that would take place was not made clear > > beforehand. > As it happened, James and I were staying at Ryan's, and after dinner on > Friday night (before the meeting proper started, but after we'd met > everyone), we chatted about the topic and came to the opinion that > removing a bunch of architectures from being release candidates would be > necessary -- for reasons I hope are adequately explained in the > announcement, the announcement didn't really contain any explanation of the reasoning behind the actions proposed (other then 'we think this will help realease') > > As a result, the rest of the project had little input into > > the decision-making process. > > That's why it's posted on the lists now -- it never too late to get > input into something in Debian; even after we've committed to something, > we can almost always change our minds. er, saying "we've committed to this" really comes across as a 'fait a compli' to a lot of people. Reading on I realize that's not what you intended. The nybbles suffered from similar unfortunate phrasings > > Do the other candidates believe that this > > was the best that could be done in the circumstances, and if not how > > would they avoid similiar situations (and the ensuing fallout) arising > > in future? > > Really, I think this is a necessary consequence of having small meetings > of the relevant people; the alternatives are to invite everyone -- which > is more or less the same as just having the discussion on the lists, > which has its own problems that I hope have adequately been covered > elsewhere; or to have meetings that don't generate any conclusions -- > which strike me as a waste of time. The combination of not including reasoning behind decisions and the rather unfortunate phrasing used in the nybbles opens you[1] /wide/ up for abuse, resentment, and acusations of being a cabal (a situation a doubt anybode was looking for). > I don't think that's actually such a problem; in this case there really > just aren't so many alternatives, and as frustrating as that is for the > people who lose out, until there are some workable alternatives, well, > que sera sera. > And given the plan is to give porters fairly complete > control over their architecture in unstable, rather than necessarily > expecting it to be synced with i386; and to provide a snapshot facility > for doing releases, I think this is actually /better/ than the current > situation for non-release-track architectures. Certainly I think it'll > be better for the Hurd than what we currently do, provided they can get > their act back into gear and meet the qualifications for being in Debian > at all. again I'm missing why's here, it may be obvious to members of the release team, but it's not obvious to me (nor it would seem a lot of other people on the list), and an "I think" does not tell me anything. > Personally, I'd much rather worry about the technical side of things and > let the "But you didn't follow procedure / respect my feelings" side of > thing slide; personally, I think the best way of feeling good when > working on a technical project is to get the technology right. if you want a technical discussion instead of a political one it helps to precisely lay out: - the precise problems you're trying to fix as opposed to just assuming everybody knows the exact problems. - how you're proposal will adress those problems Presenting the argument in whole (instead of just the result) tends to go a long way in having a technical discussion, it keeps people from feeling left out of the loop, and it accomodates and promotes a technical discussion. It also avoids repeating arguments had in the "in person meeting" with people on the list who weren't there. So could somebody who was at the meating please post and explain the why's behind each decision? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpvBM3YNULJw.pgp Description: PGP signature
Re: Debian makes titles
On Monday 14 March 2005 20:47, Aurelien Jarno wrote: > Debian drops mainframe, Sparc development > http://www.theregister.co.uk/2005/03/14/debian_reduced/ which mentions 2 or 3 times that it's a _proposal_ and concludes that given the amount of debate going on there are likely to be substantial changes to the it. > Debian to drop most architectures > http://lwn.net/Articles/127515/ seems to be a literal repost of de devel-announce mail, with an added heading, and the first comment stressing that it's a only proposal, not an a decision by the project > Are you happy with that? the headlines are unfortunate, but anyone actually reading the articles won't be misinformed -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpEvMNh6poz9.pgp Description: PGP signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 17:46, Thiemo Seufer wrote: > John Goerzen wrote: > [snip] > > > > - the release architecture must have N+1 buildds where N is the > > > number required to keep up with the volume of uploaded packages > > > > > > - the value of N above must not be > 2 > > > > It seems to me that if an arch can keep up with builds, why impose this > > artificial restriction? > > I guess in order to have an assured minimum build time for critical > packages like security updates. if that's the point it would be a lot simpler to simply say "security updates" will be announced x days after they enter the queue" -> no waiting on architectures that are slow -> no dropping any arches that manage to keep up (regardless of wether they are used by a large percentage of users or not) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpVoZoHP9VjD.pgp Description: PGP signature
Re: NoX idea
On Friday 04 March 2005 10:22, Benjamin Mesing wrote: > > Thats not true. Read the Debian Policy. Its just that some other > > distributions use runlevel 2 for console mode. In Debian thats all up > > to the user/administrator of the system. Of course we can change this > > but its not true currently. > > Sorry, consider me spoiled by SuSE which I am forced to use at work > (better than Windows though :-) I thought this part was common. > Are there any efforts to standartise the runlevel configurations going? see http://www.linuxbase.org/modules.php?name=specrev&url=http://www.linuxbase.org/spec//booksets/LSB-Core-generic/LSB-Core-generic/set1.html for what the LSB has to say about the subject -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpbRLjIqEoFk.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sunday 20 February 2005 23:57, Dirk Eddelbuettel wrote: > Clint Byrum spamaps.org> writes: > But then it doesn't matter anymore. These days, Debian is > "infrastructure". We no longer make releases. We provide the basis from > which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian > dists etc pp. em. at least for CDD's this is false, CDD-releases build on Debian releases as the only differences between a CDD and Debian are: - the initial set of installed packages - the default configuration of those packages (- some additions/changes not _yet_ added/merged back into Debian proper) CDD's are currently based on Debian-stable (which is the reason Skoleinux, for example. is still using kde 2.2), and eagerly anticipating the release of Sarge -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpaHE3oNI8da.pgp Description: PGP signature
Re: scripts to download porn in Debian?
On Tuesday 25 January 2005 23:08, Tristan Seligmann wrote: > On Tue, Jan 25, 2005 at 22:34:12 +0100, cobaco (aka Bart Cornelis) wrote: > > every parent [1] will have to go through the list of available comics, > > evaluate them and disable them. > > They'll have to do this anyway if they're not satisfied with whatever > the defaults are. yes, but by making it easy for groups of people [1] to create groupings, they can divide the amount of work necesary over a number of people, and similar minded folks that come along later can just use a ready made list. [1] note that I'm not suggesting you create those categories, IMO that's best left up to whatever person/special interest group thinks a certain categorization is worthwile, you just provide the mechanism that allows them to easily scratch their itch. > This all seems like major overkill. Does anyone really need this kind of > fine-grained control over disabling comic modules? If you just want > Dutch comics, then don't download anything except Dutch comics; ok, but how do I know what the Dutch comics are? Dosage does not (yet) contain an unwieldy number of comics. Though looking at the changelog [2] there are already close to a 100 supported comics, with that number rising rapidly. I have no Idea how many web comics there are, but likely several thousands (if not more), and ideally dosage would support them all, no? As the number of available comics grows, so does the utility of being able to categorize those comics (and say limiting myself to those comics in languages I/my kids understand) [2] The changelog doesn't include dates, so I'm not sure, but sofar I got the impression that this is still a very young piece of software > the typical use case is to run "dosage -c @" from a cronjob, which will > update the comics that are already present in your comics directory. easy enough /once you've made your selection from the available comics/. This doesn't help with deciding which of the (potentially great number) of supported comics you're interested in. > Categorization along these lines is quite a subjective issue; see [1] above > perhaps having comics organized into categories is useful, but I'm not > sure that supporting it along the lines you've described is worth the > complexity. the only thing that my proposal changes is the initialization routine of the list of comics dosage shows, surely this is not overly complex? Depending on configuration you either: 1) start with all comics, excluding unwanted subsets 2) start with nothing and only include wanted subsets 3) start with a list of wanted subsets, and exclude unwanted subsets (this option might be going a bit far, but still easy enought to do I think) 1 should be the package default IMO, 3 would be nice but 1 and 2 would be sufficient -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgph3NeUBLJKV.pgp Description: PGP signature
Re: scripts to download porn in Debian?
On Tuesday 25 January 2005 23:08, Kalle Kivimaa wrote: > "cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes: > > every parent [1] will have to go through the list of available comics, > > evaluate them and disable them. > > Isn't that required in any case, if the parent wants to do content > checking? There is absolutely no guarantee that whatever grouping > scheme might be implemented by the package authors / maintainer would > correspond 1:1 with the wishes of all possible users. no grouping scheme will correspond 1:1: with the wishes of all possible users true: The point however is that these groups don't need to be implemented by the maintainer of dosage. Whatever groups think that a certain grouping scheme would be usefull can easily create their desired grouping (and share it similar minded folks in the form of a simple file to be dropped in a agreed upon directory) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpHf6HtKSn30.pgp Description: PGP signature
Re: scripts to download porn in Debian?
On Tuesday 25 January 2005 20:53, Tristan Seligmann wrote: > On Tue, Jan 25, 2005 at 04:30:08 -0600, Ron Johnson wrote: > > The problem is things/websites/etc that "many" parents don't think > > are appropriate for their children. > > > > "They" don't want this inappropriate material dumped into their > > children's laps right along side the things that the parents *do* > > consider appropriate. > > After some discussion with the other upstream authors, the current plan > of action is: > > The next release of Dosage will check both /etc/dosage/disabled every parent [1] will have to go through the list of available comics, evaluate them and disable them. -> IMO it would be better to have /etc/dosage/disbled be a directory in which to drop lists of unwanted comics. That way whatever groups take offense/don't want a group of comics can easily (they don't need to mess with your packages conffile) create a package that disables a certain kind of comics. This is still a problem on upgrades though, if dosage includes new comics, and you upgrade before the filter-unwanted-comics-package is upgraded you could end up with unwanted packages. hm, how about this: - have a /etc/dosage/collections directory you can drop a files. The name of the dropped file is the collection name, the contents of the file is a list of supported comics making up the collection. - add the option for the admin to block access to comics of category X, or to only allow access to comics of category Y -> the building of collections can be done by however feels it's usefull to categorize comics according to some criteria -> collections might group the available comics according to subject/style/ genre/language/... which would be more broadly applicable then just kid friendliness (e.g. user only wants Dutch comics/ doesn't want comics dealing with religion, ...) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpoljF8u9sIL.pgp Description: PGP signature
Re: rudeness in general
On Monday 10 January 2005 23:03, Ron Johnson wrote: > On Mon, 2005-01-10 at 21:11 +0100, Wouter Verhelst wrote: > > Op ma, 10-01-2005 te 13:24 -0600, schreef Ron Johnson: > > > On Mon, 2005-01-10 at 19:14 +0100, Wouter Verhelst wrote: > > > Do you *really* think that RTFM means "Go read the documentation, > > > that's what it's for"? > > > > I fail to see the point of this, but for the sake of the argument... > > > > Yes, I *really* think that RTFM means "Go read the documentation, > > that's what it's for". Not literally, of course, but that's the message > > people are sending you when they say "RTFM". > > You must be a diplomat, because when *I* write RTFM, I *mean* > RTFM... As far as I'm concerned RTFM means: Read The F Manual Where, depending on your level of frustratrion and the actual quality of the manual F pgpIZ8OID9FS3.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Saturday 11 December 2004 14:28, Hamish Moffatt wrote: > On Sat, Dec 11, 2004 at 01:24:32PM +0100, cobaco (aka Bart Cornelis) wrote: > > On Saturday 11 December 2004 01:13, Rich Walker wrote: > > > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > > Rich Walker <[EMAIL PROTECTED]> writes: > > > > > > [3] Non-US exists because export of strong crypto from the US is an > > > illegal act in the US. Hence, Debian has already accepted that > > > local laws trump idealism. > > > > actually non-us is a good example of letting packages into Debian > > despite it being illegal in certain areas. > > Not really. The rest of the explanation for non-US is that those > packages weren't illegal to USE in the USA, but were illegal to > EXPORT. We don't have a section for packages that you aren't > allowed to have, or aren't allowed to use. point taken, make that: non-us is a good example of letting packages into Debian in a way that avoids it trumping local laws. -> if it's illegal to ofer it on don't offer it there, but keep it elsewhere > I'm all for omitting hot-babe just because it's more cruft. > How many CPU monitors can we possibly use? I'm not too concerned > about where it's legal for adults to use it. If we have a DD wanting to package and mantain some cpu-monitor, then we obviously have at least 1 person who: 1) thinks the package is worthwhile 2) is willing to do the work to support it as part of Debian Given that on what basis do we decide which cpu-monitors[1] meeting the above we allow in, and which we don't? First x of any category are allowed, is not a good solution IMHO (and definately less then ideal). Moreover why should we decide any such thing? Why should we not offer software for which some DD meets 2) above? It simply gives our users more options, which (IMHO) is a good thing. [1] or text-editors, or MTA's. or ... -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp3rhgQnS7YZ.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Saturday 11 December 2004 01:13, Rich Walker wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > Rich Walker <[EMAIL PROTECTED]> writes: > [3] Non-US exists because export of strong crypto from the US is an > illegal act in the US. Hence, Debian has already accepted that > local laws trump idealism. actually non-us is a good example of letting packages into Debian despite it being illegal in certain areas. As discussed elsewhere in this thread this translated nobody is against giving people the option of classifying packages in Debian (into 'legal in China', 'not legal in China', ...), and giving people the option to easily exclude packages in a certain category. ). Provided off course that: the people that care about such classifications do the actual work (and not offload it to the rest of us) At least one mechanism for making classifications is available (debtags), though a mechanism for exluding packages from mirrors/CD's based on tags seams currently to be missing. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpY3ZZiuVlPN.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Monday 06 December 2004 08:01, Ron Johnson wrote: > On Sun, 2004-12-05 at 22:49 -0800, Don Armstrong wrote: > Umm, all animals (except humans) are naked. :-O and here I always thought I was naked underneed my clothes! -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp4kLzgsijAn.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Friday 03 December 2004 03:25, [EMAIL PROTECTED] wrote: > On Thu, Dec 02, 2004 at 07:18:58PM +0100, cobaco (aka Bart Cornelis) wrote: > My opinion is that if master or non-us can't distribute it and we find > any interested mirror which can and would distribute it, then Debian > should make it possible. full ack > But since someone > can point it out that there are issues distributing any software, we > should search for a mirror where we could be located and try to get > people to be concerned about those packages. I think in most places you can be reactive instead of proactive, i.e. include by default and only remove things if they are identified as illegal (in restrictive regimes you probably wnat a group doing this proactively though) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp5OLm43hePs.pgp Description: PGP signature
Re: package rejection
On Friday 03 December 2004 06:19, Kevin Mark wrote: > Hi fellow debianista, > the package in question has not yet been accepted. > For a pacakge to be accepted, here is conditions some have mentioned: > 1) dfsg-free IMHO the only requirement debian as a whole should care about. > 3) has to be able to be mirrored by all mirrors based on the laws of the > location of the server Definately not, lowest common denominator would exclude an awfull lot (if not most things) I think the right solution here is to create some debtag scheme to easisly tag packages as 'illegal in ', and in addition adjust the mirroring/CD-building scripts to easily exclude all packages tagged/not-tagged a certain way. That way once a package is identified as being illegal in some jurisdiction (by users/developpers in that jurisdiction) it can be tagged, and hence automatically excluded in that jurisdiction (but still be available for all users for who the package _is_ legal) Note: in more repressive jurisdictions it might make more sense to exclude everything that's not explicitly tagged as legal > 2) can not be sexist > 4) can not offend someone's religion > 5) must be able to be installed by minors > 6) can not be off-color sexually or culturally define sexist (their will be lots and lots of gray areas) define minor (differs from region to region, as does what's legal for minors) define off-color sexually/culturally (again large differences of opinion) -> there is no 1 answer in these questions, therefore it's not reasonable to confine Debian (as a whole) to whatever your particular sensitivities happen to be. That said it should be easy for any group that cares about a particular issue strongly enough to: - tag things as acceptable/unacceptable (debtags already allows this AFAICT). - build a mirror/CD/installation that excludes everything tagged a certain way (or that only includes stuff tagged a certain way) As to legal in certain areas, I think in a lot of places we don't need to be proactive, we can suffise with just removing things (from mirrors/CD's in that jurisdiction) whenever somebody points out something is illegal. In more restrictive places we'll need some team of developers+users doing that proactively (or not have a mirror there). -> Everybody (that cares enough to do the work) gets to have their cake and eat it to, meaning Debian caters to the users of all the different groups -> Debian is not burdoned with > does it have to pass all of these, all the time? not possible to satisfy all such concerns -> definately no > does it have to pass different condition for the cd's that people > distribute? ie. would it be ok to force its exclusion on cd#1 but > include it on one/all debian mirrors? have the CD-building/mirroring scripts use all packages by default, but give the option to easily exclude groups of packges > what about different mirror and cd creation rules? as said above I think having a mechanism to define rules exclusion/inclusion for CD/mirror-creation is I think the way to go -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpNMH5uaben5.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thursday 02 December 2004 14:02, Hamish Moffatt wrote: > On Thu, Dec 02, 2004 at 03:36:50PM +0900, Mike Hommey wrote: > > On Wed, Dec 01, 2004 at 04:06:13PM +, Helen Faulkner <[EMAIL PROTECTED]> wrote: > Really, you can't see any difference between kde and hot-babe? between the kde-cpu monitor and hotbabe ? not in any meaningfull way (viewed through my rose-colered glasses off-course :) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpIWqECSEvup.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thursday 02 December 2004 12:47, David Schleef wrote: > On Thu, Dec 02, 2004 at 08:03:42AM +, Helen Faulkner wrote: > > Yes, you are being absurd. Since you are presumably not understanding > > the point, let me explain more clearly: > > > > Pornography is widely regarded as being demeaning and insulting to > > women. > It's a pretty common feeling to dislike something you don't > understand. Especially when repeatedly told to dislike it. Perhaps > the porn by itself is neutral, and the oppresive cluture around it > is what causes it to be demeaning. hear, hear > (btw, is gay porn demeaning to women?) or femdom porn (if so I'd _really_ like to hear the reasoning behind that verdict) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpi1F29vbprt.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thursday 02 December 2004 17:15, Mike Hommey wrote: > On Thu, Dec 02, 2004 at 12:28:20PM -0200, Fernanda Giroleti Weiden <[EMAIL PROTECTED]> wrote: > > A lot of men don't think the cartoon is pornography. > 2. Please take a look into a dictionary for the definition of >pornography. I did : foldoc, gcide, wikipedia, and the merriam-webster on my shelf all include some form of 'with the goal of sexual arousal' in their definition of pornography. Given that the (primary at the very least) goal of these pictures is to give an indication of the CPU-load they are arguably not pornographic (and IMO if the goal _was_ sexual arousal they fail horribly) Of course opinions of what is pr0n and what is not differ wildly, there was a case in America a while back where a parent was convicted as a pedofile for taking a picture of his 3-year old playing with a sausage at the kitchen table, apperently the sausage was a phallic symbole which made the whole thing porn, and another where the picture was of a baby breastfeeding (hm I'm hungry, I guess that shows, me is off to eat) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpE9xlZUYwbv.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thursday 02 December 2004 15:47, John Goerzen wrote: > On Thu, Dec 02, 2004 at 12:28:20PM -0200, Fernanda Giroleti Weiden wrote: > > "It is also the type of discussion that deterred me > > from becoming involved in Debian for some time." > > > > http://lists.debian.org/debian-women/2004/12/msg00011.html > > Indeed, and in addition to the powerful legal arguments, this is another > powerful argument. for not including this package? "type of discussion" is a culture thing completely unreleated to this package (other then that this ITP is an instance that brougth this kind of discussion forth) > If our goal is to advance the cause of a Free operating system, then why > should we be including, in our OPERATING SYSTEM, images that serve no > useful purpose, and instead alienate millions or billions of people > worldwide? How does this advance our stated priorities: our users and > Free Software? The only thing that including this package does is give our users the _option_ to install this software conveniently. > Does anyone seriously think that we are being a > disservice to users because we don't have porn integrated into the > operating system? Offering the possibility to install 1 package out of 15000+ is hardly 'integrating into the operating system', more like 'offering an optionionel extension'. (as to the 'pornographic': given that foldoc, gcide, wikipedia. and the merriam-webster on my shelf all include 'with the goal of sexual erousal' or some such in the definition of pornographic, and given that the (stated) goal of these images is to display an indication of the CPU load they arguably aren't pornographic.) > Does anyone seriously think that including these > particular images would be such an overwhelming benefit? nope, then again the same can undoubtfully be said about most of the other 15000+ packages. > Regardless of our personal opinions on this particular question, the > fact remains that it is deeply offensive to many people. This is not > the right way to show people that Free Software is the way to go. By > all means, let's be open and inclusive and accept Free software from > everywhere and users from everywhere. But at the same time, we don't > have to accept images from everywhere nor any developer that knocks at > our door. > This is not our fight. Let's fight for Free Software, and let others > battle this one out. by actively excluding it you're making a stand in that fight, as your making a choice for your users (thou shall not use this software!). It is impossible for Debian to cater to all different ideas of what's acceptable and what's not (prOn-lovers is just as valid a group as prOn-haters). For that reason alone it's rather pointless for Debian _as_a_whole_ to enforce any kind of policy (beyond 'it must be Free'), What we _should_ do is make it easy for any group/person to exclude on CD's/ mirrors/installations whatever they find offensive/unacceptable. At the moment is perfectly possible to exclude whatever you find offensive from you own installation, what appears to be lacking is an easy way to exclude those packages from a CD/Mirror (maybe something like an 'exlude everything with a certain debtag' option for the CD/mirrorring scripts) Any group of Debian users that cares enough about an issue (whether prOn, religion, politics, vi-usage, ...) can then make their own set of metadata to distinguish things acceptable from things unacceptable. It is not (and should not be) Debian's job to cater to their sensitivities. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpiM5V8AOnzB.pgp Description: PGP signature
