Re: GR proposal: code of conduct
[Jonathan Dowland] I think the increasing importance of IRC for people to keep up to date on developments in Debian is a bad thing as it excludes people who cannot use IRC regularly enough (such as myself). Increasing importance? What has changed? I don't have the impression that IRC is any more central in Debian development than it was 10 years ago. People said the same of the Debian Planet blog aggregator a few years ago - that if you couldn't find the time and inclination to read everyone's blogs, you'd miss a lot of Debian development. I don't think that turned out to be true either. I think most people still understand lists.debian.org or it didn't happen. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140308002626.gb4...@p12n.org
Re: Presentation of iso downloads - simpler like Fedora?
[Steffen Möller] some binary software forced me into downloading a RedHat flavour, so I went for Fedora. I found it very easy to get an ISO. I mean - very very very easy. My suggestion is to copy that for our now pending release or to make it even easier Hmmm, they have a button labeled Download Now! that links to a 64-bit live ISO. We have a button labeled Download Debian 6.0 that links to a 32/64-bit installer ISO. They have a more options link to a page that lists a zillion images plus a large section devoted to some non-free cloud computing platform. We have a Getting Debian list on our main page that links to various pages full of install image stuff. I guess I don't get how theirs is easier. Well, unless you happen to want to use that specific non-free cloud computing platform. Other than that, the experience seems pretty equivalent. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120810184205.ga5...@p12n.org
Re: trademark policy draft
[Paul Wise] Does the domain name restriction mean that sites like these will have to rename themselves? http://www.debian-administration.org/ http://www.debian-news.net/ The way I read it, it's not that sites like these will be forced to rename themselves, but that they will be forced to seek explicit permission to use the trademark. Peter -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120731195313.gb4...@p12n.org
Re: revenue sharing agreement with DuckDuckGo
[Philip Hands]
Should this not be a debconf question, along the lines of popcon, but as
a machine wide:
Do you mind trading a little privacy to allow us to declare your use
of Debian to search engines, and thus possibly benefit from revenue
sharing arising from your searches?
Why even bring up the money? The question of should we expose that
you're running Debian is so much bigger than DDG.
- Debian-specific 'User-Agent' string in some (most?) browsers
- Debian-specific default home page portal thingy for some browsers
- {n}.debian.pool.ntp.org default NTP server list (telling the DNS
admins of pool.ntp.org)
- Default apache index.html (or is that Debian-specific these days - it
used to be, at least)
- Debian-specific sshd banner
Granted, the last two are server side, not client side, but the point
is, there's all sorts of ways for the rest of the Internet to know
you're using Debian, not just nmap.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120328150139.gb2...@p12n.org
Re: revenue sharing agreement with DuckDuckGo
[Stefano Zacchiroli] What they propose is: - donating to Debian 25% of the income they make from inbound traffic that originates from Debian users if DDG is a search engine option in a web browser - donating to Debian 50% of the same income if DDG is the default search engine I suggest that we explicitly refuse the second option, so that we cannot let money influence any browser maintainer's choice of default, either in appearance or in reality. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120327175821.ga2...@p12n.org
Re: 1 year release good enough.
[dE .] Look what Microsoft and Apple's is doing with Android. And for any task with WP7, you have to have propitiatory applications which're Microsoft, Apple, Android, and WP7 (whatever that is) are all off-topic. The debian-project list is about the Debian Project. You may hate technology companies that are not aligned with Debian in some way, and that's fine. You might be morally offended that some company has a lust for money and power, and that's fine too. But it has nothing to do with what we do here. Please take it elsewhere. Whoever you are. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120105100348.ga12...@p12n.org
Re: Logo violation
[Alain Belkadi] Maybe not the right place to send this info but someone is using the Debian Logo on a film festival website. Thanks for the report. As already noted, that logo is open-use, you can use it for pretty much anything. Beyond that, it is an unfortunate fact that our open logo is _very_ similar to a custom brush shape shipped in Adobe Photoshop. (Our logo was chosen in a public contest; I suspect if anyone had noticed this when we chose the logo, we would have disqualified it.) The Photoshop brush probably explains many instances of borrowing: other people incorporate the same Photoshop brush into their own graphic designs and logos. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110929191608.ga1...@p12n.org
Re: DEP-5 meta: New co-driver; current issues
[Lars Wirzenius] * Quite a number of packages already use some variant of the DEP-5 format. There's no goal to make using it mandatory, however. (Compare with debhelper: almost all packages use it, but it's entirely optional.) and then you say If we build DEP-5 outside the normal project structures, we'll just have to re-discuss it when it's time to approve it, so it's better to have the discussion just once. So, you guys keep saying this is just like debhelper in that it won't be mandated, just something a lot of developers will adopt, aiming for enough critical mass to make it useful. You almost protest too much. But if you start talking about when it's time to approve it on debian-project, the comparison breaks down. Why does DEP-5 need to be approved? And by whom? Nobody had to discuss and approve debhelper. Because it's optional. Because nobody is forced to use it. Oddly, I'd feel better if the project drivers were _not_ trying for explicit Project approval. (A strange position, since I'm usually opposed to cabal-based decision making.) Peter -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100813233349.gb8...@p12n.org
Re: DEP-5 meta: New co-driver; current issues
[Lars Wirzenius] * a Comment field would be good * license shortnames/keywords: the set of keywords probably needs work, and hopefully can be compatible with what other projects use; the current thread on the meaning of public domain is part of this * file globbing syntax * clarify the text so it's clear DEP-5 won't require more precision than is currently needed Is it worth adding metadata to make it easy to extract all the acknowledgements you have to add to your advertising materials to comply with old 4-clause BSD licenses? It wouldn't benefit me, but maybe it would benefit CD vendors. Of course, I'd hope there isn't too much software in Debian anymore that still has those clauses. To people new to free software (10 years or less), see http://www.gnu.org/philosophy/bsd.html for a pretty good summary of the issue I'm talking about. Peter -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100814015911.gc8...@p12n.org
Re: buildd/porter/maintainer roles again
[Wouter Verhelst] Please remember that every time a package fails to function correctly on a particular architecture, barring toolchain bugs, this is a bug in that package itself. Barring toolchain bugs is a pretty big caveat. Just as big as barring kernel and libc issues, some other reasons for packages to fail to build or run on particular architectures. There is a perception, which may or may not be grounded in reality, that _most_ FTBFS from the Debian buildds are either toolchain, kernel, or libc issues. It is certainly my perception. And it seems to have been a toolchain issue that started this thread (some mips buildd simply cannot not build Java stuff, as I recall). Do you, as a porter and buildd admin, have a rough idea what percentage of FTBFS and arch-specific bugs you see that are ultimately a bug in the package, versus an externality like a bad build chroot, bad kernel, bad system library, or bad toolchain? If we're talking about 90% vs. 10%, for example, that would inform who should really be on the front line triaging this stuff. Peter -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727220112.ga8...@p12n.org
Re: debian-private declassification team (looking for one)
[Andreas Tille] I do not want to stop any volunteer to do the work. I just doubt there will be anybody. In other words, 1. You think declassification is not worth anyone's time 2. You are not volunteering to do it 3. You don't want to stop other people from volunteering to do it Why even bother to post? Seems to me you could have accomplished all three points by just not hitting Reply. My ulterior motive in this suggestion was: How we can practically find out whether some is *really* interested in a work which consumes a team of DDs spare time. What does that matter? There are lots of things DDs do that we don't know for sure if any users will care. If you don't want to waste your time doing those things, then don't. But what's the point of a thread discussing whether or not somebody other than you will decide to do some work you don't think is useful? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100625220522.ga3...@p12n.org
Re: Bash version 4
[Norm Armstrong] I was wondering if you have an estimated date for including Bash version 4 in the stable release packages? Won't happen in Debian 5.0 lenny - stable releases never get major software updates, and only get minor updates if they fix really bad bugs. bash 4.1 be in Debian 6.0 squeeze, but when that will be released is anyone's guess. Probably not sooner than 3Q of this year. Maybe later. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
[Julien BLACHE] I think we'll lose part of the we release when it's ready philosophy (that our RMs seem to despise so much). Because part of this is to freeze when it's ready. I still don't understand what is supposed to be new about the time-based freezes. The Release Team was giving us projected freeze dates all through the lenny release. For example, http://lists.debian.org/debian-devel-announce/2008/02/msg2.html Of course we weren't able to hit every freeze date ... but so far I haven't seen any reason to believe that aspect of Debian will change. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
[Pierre Habouzit] It yields a really costly entry point to target Linux as a platform, and it's exactly why most Software Vendors target RHEL and not Linux. And that's part of the reason[1] why most of our customers are using RHELs: software vendors only certify their stuff for RHEL, because it's the established reference in the field, and that it costs too much to certify you stuff for yet-another-distro. Ahhh, so you're trying to reinvent the LSB. You could have said so earlier, it would've saved some time. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
[Luk Claes] Who would you like to propose a release cycle to the project if not the Release Team? So this is a proposal? The Vancouver proposal should have taught us a lesson: when you announce a big change, if you truly intend for it to be a proposal to be discussed, you have to state this clearly, or people will get upset at what they see as a fait accompli. Why doing a 12 months release to get into the new schedule instead of just adopting a 24 months schedule based on the lenny release? The main reason is that the Release Team hopes to now have the momentum to make a time based freeze work. If we would delay, it will very probably mean that many developers 'forget' about what the time based freeze is about. This rationale doesn't seem very plausible, for two reasons. First, what need is there for momentum? Announce the freeze will be in Dec 2010 and, if you think we will forget about it, periodically remind us via those bits-of-the-RMs style mails. Second, what is new about time-based freezing? Wasn't that what we did for lenny? The release team had a graduated freeze schedule in place well in advance, and tried hard to stick to it. What is different next time? There've been a lot of rumors that the 10 months until squeeze freeze has more to do with trying to benefit Ubuntu LTS, than anything about momentum. This unfortunately sounds a lot more plausible to me. If it is correct, I'd rather you just said so up front. (For the record, it still wouldn't make me _happy_. Cui bono? I believe freezing four months before an Ubuntu LTS release would not benefit Debian at all. Freezing _after_ an LTS release, or at least after an LTS freeze, would help Debian quite a lot more.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
[Stephen Gran] That just means that the number of people who think the vote is even worth having is not that different to the number of votes required to make it valid. That's probably not all that bad a thing, IMHO. If that is sound reasoning, then it is also a reason to have a higher number of required sponsors for amendments to foundation documents. That said, I think I agree that 2Q is too high but current K is too low. (Split the difference? Q + K/2) Another issue with raising the bar is that if you formally propose something before it is fully ready, such that it will need two or three small modifications, it would get very confusing who has seconded what versions of the text - guaranteed great fun for the Secretary role. Not a new issue, but it would get worse. I suppose this would serve as social engineering to encourage people to circulate drafts for awhile before proposing them. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#292330: use UTF-8 by default
[Thorsten Glaser] [...] a hypothetical C.UTF-8 locale, which would have to be set via setlocale(3) anyway, and differ from C only in LC_CTYPE category. I suggest a strategy of having locale.config (the script that prompts you to generate locales at install time) automatically select any locale which matches s/\..*/.UTF-8/ for the locales the user has selected. Of course, some users may be annoyed by the additional disk space (what, another megabyte or so in /usr/lib/locale/locale-archive?) and the additional CPU usage at install/upgrade time. signature.asc Description: Digital signature
Re: Social Committee proposal
[Josip Rodin] I also think that a social committee would be a good idea. Even if unrefined and/or undefined, just the notion of having both a technical and a social committee would indicate major progress in our way of thinking. Pretty words. What problem is this supposed to solve? What benefits can we expect from major progress in our way of thinking? This one could be tricky to phrase. Maybe - Decide on any social matter, including social norms and customs, non-technical communication among developers, and day-to-day organization matters within the Project. For example? For every social problem I can think of in Debian, the solutions are not enforceable by a committee vote, unless you give them the authority currently held by the DAMs, listmasters and ftpmasters. That is, the only ways I can see to effect social reforms is to be able to throw people out of the project, or restrict their list postings, or restrict their uploads. Anything less is just empty gestures. People who cause social problems don't stop just because someone asks them to stop. Or is this, just like way too many other threads in Debian, really about Sven Luther needing a better ombudsman? Perhaps you need to import a bit more context from -private. signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
[Matthew Garrett] The biggest area which is likely to bite us is with network cards, though we'll probably lose some degree of SCSI support as well. Fortunately, at least with SCSI, users have a choice. They can buy Adaptec or LSI 53c* and they get _truly free_ firmware (in the case of Adaptec, the kernel includes firmware source and a matching assembler; for LSI, the firmware is augmented with byte-code scripts apparently assembled by the driver at runtime). Perhaps coincidentally, between aic7xxx, aic79xx and sym53c8xx_2, the most popular commodify SCSI chips are covered. (Well, there's the megaraid family, but those don't _appear_ to need to load firmware at runtime either.) Incidentally, the aic7xxx / aic79xx drivers in particular are a great thing to point out to people who are inclined to be lenient toward vendors on the theory that it is inherently not practical for them to ship open source firmware for their devices. Adaptec figured out how to do this a _long_ time ago: $Id: aic7xxx.reg,v 1.4 1997/06/27 19:38:39 gibbs Exp $ $Id: aic7xxx.seq,v 1.77 1998/06/28 02:58:57 gibbs Exp $ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
[Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. signature.asc Description: Digital signature
Re: Reforming the NM process
[Panu Kalliokoski] Now seriously, the reasons why a package in Debian is quite different from a Debian package outside of Debian should be well-known enough: ease of search and use for users and infrastructure for packaging (such as the BTS). Those are minor things compared to the reputation of the Debian Project for doing high-quality packaging. Package quality, aided by a thorough Policy document which all maintainers aim to comply with, is what makes Debian something more than just a huge pile of free software in someone distribution's contrib directory. As such, I'm strongly opposed to anything related to letting people who don't know what they're doing stick their own packages into the archive without anyone checking them closely. For the rest, you're dreaming, we're not going to give vote rights instantly. It doesn't make any sense. Probably not, although I doubt there's anything horribly wrong with it. But I would give vote rights instantly, so who is this we you're talking about? Please do read the rest of this thread, Manoj gave a very good answer to this one earlier. The right to vote is the right to change the future directions and core principles (e.g., the Debian Free Software Guidelines) of the entire Project. It comes in exchange for a certain commitment to the Project that random contributors and other users have not made - even valuable contributors like the authors of GNU libc. The way to make that commitment is to become a Debian Developer. Besides, there is no value in a wide-open voting system. This is called an Internet poll and the results generally reflect whatever websites or blogs happen to publicise it. signature.asc Description: Digital signature
Re: mailbox clogging, need daily digests of the list
[Floris Bruynooghe] Very nice, but can I give mutt a rule that will look in all mailboxes too? In mutt you have to set 'mailboxes =debian-project' or similar, but it would be nice to have a autmatic rule too otherwise mail will get sorted in places where I'll never see it! Well, I have: mailboxes `echo $(find $HOME/Mail -type f)` But I guess it only executes that at mutt startup time, so if you get lots of dynamic mailboxes created, it wouldn't help all that much. signature.asc Description: Digital signature
Re: Emphasize teams, not packages
(M-F-T set.) [Frans Jessop] When somebody wants to become a DD he is told ?Go find a package to maintain, one that you can be the maintainer for.? I see serious problems with this approach as Debian increases in DD's. I will how this is in a second. What I think should be emphasized is ?Go find a package team and join it and contribute and show your stuff.? The point of maintaining a package is to prove that you *can* maintain a package. Being on a team proves nothing. Being on a team and doing most of the work proves something, if this can be measured, but that's difficult. As it happens, I'm on at least one team where I do a majority of the work, and at least one team in name only (haven't yet done *any* work). I don't particularly expect to be judged favorably for the one or unfavorably for the other, because it's just too hard to get the data. I think Debian needs to emphasize teams packaging, not just individuals for many reasons. We've had this conversation already. So I'll skip it. Besides, there are lots of things we need to emphasise in Debian. We've had those conversations, too. Future A: There are now 10,000 DD's and over 100,000 packages, most nobody uses, they are just there because they were needed by people who wanted to become DD's. Obvious solution: Change the requirement from maintain a package to maintain a package that a significant number of people care about. Since AMs / DAMs are people rather than machines, we don't need an accurate automated metric for this - something as vague as popcon should be quite sufficient to reveal the difference between useful packages and pet packages only ever installed by people who said to themselves hmmm I wonder what this does and then never bothered to uninstall them. signature.asc Description: Digital signature
Re: Emphasize teams, not packages
[Jonas Smedegaard] It is too hard to read the changelogs where it is (or at least should be) clearly documented who from a team did what parts of the packaging. I agree that it's too hard, but I don't agree with the rest of that. The debian changelog doesn't typically say much about who's doing the testing, who's reproducing the bugs, who's forwarding bugs upstream and working with upstream to resolve them, and several other tasks the debian maintainer is expected to do. Nor does the debian changelog typically give an accurate picture of how easy or hard each line item was to achieve. Nor does it explain anything about whether the person who added the line items got them right or wrong, whether anyone else is covering for his mistakes before a package is finally uploaded. Much fuller pictures emerge from the combined logs of the version control system and the BTS, but estimating who is doing most of the work on a package based on *those* logs is a tedious and subjective process. This tedious and subjective process isn't something I'd expect an AM or DAM to want to undertake. Particularly when an example of solo maintenance is available to analyse instead. The most credit I'd expect any NM candidate to get from a team-maintained package is a few words of endorsement from co-maintainers. I think Debian needs to emphasize teams packaging, not just individuals for many reasons. We've had this conversation already. So I'll skip it. Please provide a reference to that discussion. google://site:lists.debian.org+team+maintenance The first hit is a great example, http://lists.debian.org/debian-devel/2005/08/msg00712.html and a rather long thread following. The fat subthread starting at http://lists.debian.org/debian-devel/2005/12/msg01055.html is another. It surprises me that you missed both of those threads. If you are interested in promoting team maintenance, I suggest you read them in the archives, to avoid repetition. Team maintenance, and the advantages and disadvantages thereof, is a very old and tired subject. signature.asc Description: Digital signature
Re: Automated testing - design and interfaces
[Ian Jackson] Running the upstream test suite in debian/rules usually isn't the answer to packaging mistakes, library mismanglements, and the like. I have an idea. What if we had a script that ran dpkg-buildpackage and then immediately ran lintian and linda if available, to look for common packaging mistakes. Wait, that would be debuild and pdebuild. Do you really think packaging mistakes not caught by lintian would be caught by the test suite put together by the same goober who made those packaging mistakes? And I'm having trouble coming up with the kinds of issues which are (a) not packaging mistakes per se, and (b) necessary to perform on a built package (as opposed to a build tree or install tree). I mean, otherwise your test would work fine as part of the upstream testsuite, which you should already be invoking from debian/rules. signature.asc Description: Digital signature
Re: Retailing
[Joe Smith] The difference is that Debian does not distribute the BIOS. Debian indeed does not distribute the BIOS ... _but_ whoever sells a computer with Debian pre-installed most certainly does distribute the BIOS. That is what we are talking about; please try to read threads before replying to them. signature.asc Description: Digital signature
Re: Retailing
[Michael Poole] For example, GRUB and Linux are both licensed under the GPL. Both would be included with these retail systems and would be written to locate and call functions within the BIOS; that is, GRUB and Linux would be dynamically linked against the (presumably non-free) BIOS. It has long been a perception that the computer BIOS, like the kernel, provides an API across which a program can execute without considering the kernel a derived work of the userspace programs, or the BIOS a derived work of the kernel. The same is not believed to be true of shared libraries in a userspace application. I myself am not certain what the important distinction is between those two cases, but this is very well established GPL interpretation dogma. Has it simply gone unnoticed by those who campaign so hard to kill competition? Not unnoticed. The ever-present issue of non-free driver firmware will ensure that nobody ever forgets to consider cases involving software that doesn't run in userspace or kernel space. Debian obviously can't *distribute* non-free BIOS or driver firmware, but I don't think anyone has been arguing that Debian kernels can't *use* the BIOS and other firmware supplied to the system by someone other than Debian. signature.asc Description: Digital signature
Re: implementing an official Debian backport framework for the current stable release
[Mark Farnell] To address this problem, I am thinking about a possible framework for official debian backport to the current stable release: - to create a backport repository of the most recent packages on testing that have significant improvements / addition of important functions to the public (e.g. openoffice 2.0, wine 0.9, firefox 1.5 (when it is officially released), PHP 5 etc.) The nature of Debian's archives and tools (apt, in particular) makes it very easy to do this sort of thing without being especially affiliated with the Project at all. If you feel the need to compete with backports.org, dotdeb.org, apt-get.org and other such sites, there is no need to arrange to use the official mirror network. You can even release CD images if you wish, along with normal package updates and security updates. Also, the update candidates are, of course, inherently subjective. Some people will care much more about, for example, Linux 2.6.14 or subversion 1.3.0 (not yet released) than they ever will about PHP 5. Last time someone tried to do an official backport release like what you're describing, it was known as slink-and-a-half, and apparently never was actually blessed by the Project. (My memory fails me concerning the details, and I'm too lazy to look them up, but if you are interested in this field, I'm sure slink-and-a-half is quite googlable.) What do you think about the feasibility of such a backport framework I think people in Debian-land use the word framework far too often. But that's neither here nor there. I also think competing with backports.org et al is something you should do outside the Project, until you've demonstrated advantages over these other repositories. Alternatively, you could work *with* them. signature.asc Description: Digital signature
Re: problem with mount and ...
[Wodzu Wodzowski] One is with mount command problem. I wrote in fstab file: /dev/hda2 /mnt/winD ntfs ro,user,auto 0 0 This *is* the wrong list, as mentioned - but anyway. I don't know why you use both the user and auto flags. For one thing, auto is already the default, so does not need to be specified; for another, user is usually used with noauto instead (people normally want either user,noauto or the defaults of nouser,auto). But what you do want is the flag umask=0 as explained below: /dev/hda2 /mnt/winD ntfs ro,umask=0 0 0 /dev/hda2 /mnt/winD ntfs ro,umask=0,user,noauto 0 0 (Depending on your desired configuration.) So I checked attributes of this file and use 'chmod 777 ...' and stiil don't have access to this partition. chmod does not work with the ntfs filesystem: the Linux kernel code for ntfs does not bother to read or write permissions information for files, since NT permissions are so different from Unix permissions. (User and group IDs would have to be mapped from one space to the other, and the classic Unix permission bits don't exist per se in Win32 either. Windows files have ACLs instead.) The only way to control the permissions presented is the umask option at mount time. signature.asc Description: Digital signature
Re: Thinking about (mis)use of -private
[Daniel Ruoso] The issue with -devel being too high traffic and off-topic is of course still there; That's something important. Use of a Subject: CFD: convention would mitigate this. Particularly if the convention were widespread enough to be a (de facto) standard, and thus to make it into people's MUA filters / scorefiles. I think it's also entirely reasonable for listmasters to sanction people who abuse a convention like this one. signature.asc Description: Digital signature
Re: IRC debate feedback
[Helen Faulkner] Having just run the 2005 DPL IRC debate (and a stressful experience it was too), Martin Krafft and I would like to get feedback on what people thought of the debate and how it was run. Thank you, Helen and Martin, for a job well done. I think the most useful thing would be a writeup from the two of you on how you managed the technical aspects of running the thing. There were a lot of minor technical difficulties early on in the debate but you obviously learned quickly how to iron them out - all but the first 20 or 30 minutes went quite smoothly. It would be interesting (for me, and for whoever needs to moderate debates on irc in the future) to hear how you solved problems like awkward line formatting and getting paragraphs cut off because of the limits of the medium. (Pasting from #-replies irc logs or from a live client? Per-candidate logfiles of #-replies? Use of a text editor for collection / reformatting? Etc.) Apologies if you already wrote this up and I just haven't seen it. Peter signature.asc Description: Digital signature
Re: Bits from the ftpmasters
[Matthew Palmer] Do you believe that the ftpmaster team might be amenable to either of the proposals mooted recently, such as multiple people certifying that the package is OK (like advocates for packages), or a collection of clueful DDs doing these sanity checks on NEW packages? The crypto export thing is a potential problem, but it seems to me that it has a pretty straightforward solution: host the NEW queue on a machine outside the US. Then it may as well be anon-HTTP-accessible as far as the US government would care. (Of course, there may be other reasons not to take the NEW queue public, like the possibility that something with a non-free license, which doesn't permit that sort of distribution at all, gets that far.) signature.asc Description: Digital signature
Re: New Front Desk members
[Anthony Towns] Is there any reason why grammar, porn and spam debates are attracting so much traffic? I rather suspect one factor is increasing one's visibility in the Project, without having to work on and think about technical issues. (This sort of thing has been noted before, with the send Linus spelling fixes in kernel variables and comments effect.) That seems like a silly goal, I know ... but even so, I wouldn't be at all surprised if, when you correlate hot-babe verbiage with measurable, useful Debian work, there'd be a rough inverse relationship. There are no doubt some people who do have better things to do but choose to ramble about Sexy Losers anyway - I can't explain *them*, but I suspect they're in the minority. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, lists and discrimination
[MJ Ray] Are posts which should otherwise go to other lists accepted on -women purely because they involve women? It looks that way from yesterday's list description and past activity. Is that your real concern? You should breathe a sigh of relief when you learn that the goals of the debian-women project do *not* include siphoning people away from -mentors or -devel. Quite the contrary. And if individual subscribers choose to take refuse in debian-women and never do venture out to those other lists, what is that to you? (That's a rhetorical question - no need to feel the need to answer it.) Also, ponder whether you are equally concerned when a post which really should go to debian-user ends up on debian-mentors. Or when a post that ideally is topical for debian-project ends up on debian-vote, simply because there is something to do with a vote involved. Or when a post which concerns the installer winds up on debian-devel rather than debian-boot. Face it, there is plenty of overlap between existing debian lists. And not everyone knows which list is the best to post to in every circumstance, no matter how you document it. If it really bothers you that much, feel free to subscribe to debian-women so that you don't miss any of the exciting material you expected to see on debian-mentors. I don't hear anyone except you complaining about the burden of being on one too many mailing lists as a result of this. Peter (BTW, don't expect much more out of me than what I'm posting now. In our encounter on IRC the other day, I kept trying to find out if you had more questions that we hadn't answered already, and all I got was you rehashing the same few questions over and over, apparently hoping for new answers that suited your preconceptions better than the answers we'd already given. So if I ignore your further responses, it will probably be because they are, in my judgment, covering ground we have been over many times already.) signature.asc Description: Digital signature
Re: Just a single Question for the Candidates
[Jonathan Walther] Gentlemen treat women with greater gentleness and with less expectation than they do their fellow men. A gentleman, for instance, would not think to lift a fellow man over a rain puddle, but would instantly offer such assistance to a lady. I know it has not escaped your notice, since you mentioned it earlier, that while some women enjoy the perks of your way of thinking, others find it insulting. I imagine you have heard the saying, A gentleman never wounds unintentionally. Obvious corollary: to qualify as a gentleman, you ought to be able to tell the difference between those two types of women, and respond accordingly. (I highly suspect that most prospective Debian developers would fall into the second category, but that's not my point.) That you seem completely unable to do so makes clear, if it wasn't already, your own hypocrisy and pompousness. Peter signature.asc Description: Digital signature
Re: Some Comments on Sexism in #debian
[Matthew Hall] there are 12 operators in #debian, which means we expect each one to be present at least 2 unique hours per day, assuming the task is equally divided. In my opinion that is probably not enough for a channel with 600+ people and such extreme traffic levels There are actually a lot less than 12 active ops on that channel, but on the other hand, coverage is somewhat better than you might expect due to the insane amount of attention Rob Weir manages to lend the channel. Linus's phrase about Alan Cox actually being a SMP cluster comes to mind. Which is not to say more active ops wouldn't be better. But most of the time, there *is* one around when you need one, although they sometimes need to be poked. I myself never hesitate to poke ops that I think are around, when I spot behavior that I think should be dealt with. Others should do the same - and some do. (Note: the behavior I'm talking about is actually almost never the sexist crap - there's a lot more non-sexist abuse and trolling in that channel. Complaining only about abuse toward women, and not abuse toward men, is itself a form of sexism - an implication that the women are less capable of taking care of themselves. I've actually found the opposite to be true. But my point is, it all needs to be dealt with.) Next, I would like to say some words to those who have been saying that Debian doesn't discriminate against women. As far as IRC goes, IT DOES. ADMIT IT ALREADY. I don't think anyone is disputing *that*. The question is whether, as a support resource advertised by the Project, the IRC channel on freenode is something for which Debian should take responsibility - in terms of setting and enforcing policies against abuse. And in fact, there's not even much argument about that either. I've talked to a couple of the ops, and they *are* discussing how to set and enforce a more intolerant policy. And as I said before, I do think more ops would be beneficial. Peter signature.asc Description: Digital signature
Re: Some Comments on Sexism in #debian
[Mike Beattie] Have a brain please? I was not talking about the technicalities of whatever one does on IRC... Last I looked, Debian's world domination plan did not include censorship. Censorship is entirely appropriate when it comes to maintaining some decorum in a forum such as IRC. Just as it is appropriate to forcibly remove people in a (physical) public forum who are being disruptive and refuse to stop. Peter signature.asc Description: Digital signature
Re: Just a single Question for the Candidates
[Andrew Suffield] Psychology and sociology are fuzzy sciences for the most part, where very little is proven. That does not mean that the standards for proof should be lowered, it means that their conclusions should be treated with the usual skepticism and not as things which have been conclusively proven. As may be. All your pontificating about data and proof is a fine way to avoid the actual issue under discussion, which is that a social system (the Debian Project) is exhibiting the same symptom (fairly extreme under-representation of women) as other systems which have been studied and are similar to the Project in other ways. I think it is more than reasonable to entertain the possibility that a similar cause is, in the present case, responsible for a similar result. And even to take action based on that assumption. Or do you always wait for perfect information before making a decision? Correlation across a large number of systems does *not* demonstrate that the same thing will happen in any individual system. Is this just a game to you? Did you think there were judges on the sidelines keeping notes about who was using the wrong standard of proof, or making unwarranted assumptions? It's not a game to the ones who started this thread. If you'll recall, this started with a simple question about what can and should be done about the gender imbalance in the Project. Surely it would be more productive to search for hypotheses about the causes for this imbalance, than to offer silly theories like sunspots to illustrate your point that, because the science is inexact, the real causes can never be known. If you say nothing should be done, because the essential nature of the Project is conflict, and those who cannot deal with conflict would be best advised to stay away from the Project in any case - then that's at least taking a stance. Likewise if you say nothing *can* be done, because enforcing a more civilised standard of behavior on our developers and members of our support channels is effectively impossible. Alternatively, you might say what should be done is to take surveys and collect anecdotes of people's experience interacting with the Project, so as to form a clearer picture. Any of those would be preferable to insufficient data, therefore we have no choice but to ignore the issues. Peter signature.asc Description: Digital signature
Re: Just a single Question for the Candidates
[Thomas Bushnell, BSG] I agree that Debian has a problem in this area and that it's worth worrying about and trying to fix. I do not think that Helen has given us any information about it; she is guessing at what men usually do, and imputing that to us, and guessing about how women feel. That may be true. However, you may have overlooked Erinn Clark's post to this thread, which, fortuitously, has just the sort of information you seem to be asking for. I have little to add to her post, which you can find here: http://lists.debian.org/debian-project/2004/debian-project-200403/msg00086.html All I can really add is that she's not making this stuff up. I've been on freenode::#debian for a few months now and I've seen the harassment, the unwelcome advances, the juvenile behavior, the abuse, that she's talking about. It's not all sexual in nature, to be sure - the #debian channel sometimes drives away potential *male* users as well. WRT mailing list behavior, I don't have a lot of grounds to comment - I haven't been actively following the lists for nearly as long. Peter signature.asc Description: Digital signature
Re: Just a single Question for the Candidates
[Andrew Suffield] We can't be sure whether this orange-haired person likes to eat babies or not. He probably does, lock him up. Not that a baby-eating example isn't a bit loaded ... but ok, I'll run with it: Many orange-haired people have been observed to eat babies. Here we have an orange-haired person, and babies keep disappearing. While there is still some argument on the point of whether or not it is acceptible to keep losing our babies, most of us agree that this is a Bad Thing. Maybe it is time to take steps to keep the babies away from the orange-haired person, you know, see if that makes a difference. If you want to promote some action based on your guess - go ahead. But don't try to pretend it's based on anything but a guess. See how far you get. I'm perfectly happy to suggest courses of action based on guesses backed by anecdotal evidence but not firmly proven. I'm not doing so at this time, because I'm not the one with the ideas. Is this just a game to you? Did you think there were judges on the sidelines keeping notes about who was using the wrong standard of proof, or making unwarranted assumptions? It's not a game to the ones who started this thread. It's not a game, therefore the rules (of logic) do not apply. More like - there comes a point where calling people on the carpet for what amount to technicalities is counter-productive and useless. If you're discussing going out for beer with a few friends, do you make them follow Robert's Rules of Order? My direct point was that the argument There are no other possible explanations was false. I think that's easy enough to concede. In fact, I don't remember seeing it argued otherwise. So, what alternative explanations have been offered? Occam's Razor would seem to rule out the effects of sunspots. My indirect point was that the fact that the causes cannot be known does not justify action based upon a guess as to what those causes are. Action is justified on a basis weighted by the likelihood that the theory suggesting the action is correct (i.e., the action is likely to be effective), and by the urgency of the desire to address the problem. The fact that the cause of a problem cannot be known for sure does not by itself justify action, but it also does not justify *inaction*. In other words, I would suggest that the burden of proof does not, in cases such as these, rest solely with the affirmative. If you would argue that it does -- and simultaneously that hypotheses concerning social structures cannot really be proven -- then by implication, changes should not be made to social structures at all, and you may as well come right out and say it. I could be reading you wrong, but that seems to be the gist of your earlier verbiage about not lowering one's standard for proof. But this is silly anyway. At the point I jumped in, this had become a meta-debate; now it seems to be turning to a meta-meta-debate. Since, amazingly enough, I've got other things I could be doing with my time, I'll go ahead and let you have the last word here, if you want it. Peter signature.asc Description: Digital signature
