Re: switching to vim-tiny for standard vi?
Hi, While I'm a addicted vim user, the build-dependencies of vim(-tiny) is a bit scary for a base package. While we do not have requirements of base packages of being easily buildable, changing to vim-tiny will make bootstrapping a basic debian system again a little bit harder. nvi: Build-Depends: debhelper, libncurses5-dev vs vim-tiny: Build-Depends: debhelper (>= 4.2.21), dpkg (>> 1.7.0), bzip2, perl (>= 5.6), libgpmg1-dev [!hurd-i386] | not+linux-gnu, libperl-dev (>= 5.6), tcl8.4-dev [!hurd-i386] | tcl8.3-dev [!hurd-i386], python-dev, libncurses5-dev, ruby, ruby1.8-dev | ruby-dev, libgtk2.0-dev (>= 2.2) | libgtk1.2-dev, libgnomeui-dev [!hurd-i386], lesstif2-dev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does it sometimes happen that people send mails before NMU ?
On Monday 16 January 2006 10:41, Mike Hommey wrote: > On Sun, Jan 15, 2006 at 11:31:10PM -0800, Steve Langasek <[EMAIL PROTECTED]> > > Well, no, but the fact that it's a longstanding release-critical bug, > > with no maintainer response, means that it does warrant NMUer attention. > Yes, it's my fault i didn't tag the bug or sent any feedback, but I'm > actually trying to find a better solution than removing the files, with > upstream cooperation, considering that upstream adds new testcases quite > often, and that any addition is likely to have the same problem. The correct action in this case would have been CC: this cooperation with upstream to [EMAIL PROTECTED] If you are not mailing BTS to tell what you are doing/planning to do with the bug, you can hardly blame the NMUer for it either, right? The problem with requiring mailing days before upload is the lack of instant gratification that motivates the NMUer. A delayed upload queue would seem to fix that, but in practice people seem to get active on fixing RC bugs only when the 0-day upload period is declared. Someone with more insight on human mind than I have might have an explanation for that too. Cheers, Riku -- hi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wednesday 18 January 2006 11:01, Gerfried Fuchs wrote:
> * Matt Zimmerman <[EMAIL PROTECTED]> [2006-01-17 11:36]:
> So again you are saing it's the Debian Developer's job to look around
Yes it is. and you shouldn't restrict yourself to ubuntu, checking what other
Debian derivates, Fedora, OpenSuSe or even Gentoo etc have done for the
same software you are packaging might reveal patches and changes.
It is true that all that information is not available at one central place,
which
makes this job a bit troublesome. Setting such setup should not be that
hard, it just requires LOTS of diskspace and bandwidth..
> So you are saying it's the Debian Developer's job to pull changes from
> ubuntu back? If that is an official statement, then that would be useful
> for a d-d-a mail so we are aware of it.
This is what also wonder about ubuntu-haters. Somehow it is OK for
Debian to have different opinions and preferences ("Tell me about changes"
vs "don't spam me" or "You don't Attribute my work" vs "Don't put my
name there").
But at the same time you require a explict policy from ubuntu and anytime
a ubuntu developer says something about it is considered a official position
statetement.. Until we can do a official statement of debian derivate
policy ourselfs, we can hardly require it from them..
> Do you imply with this message that Ubuntu doesn't care about quality
> in their upstreams but rather keep their stuff to themselfes?
The same can be claimed about about Debian and our upstreams. Not all
maintainers submit their patches upstream, and sometimes our lack
of co-operation have made our upstreams really unhappy (Remember micq?).
However, that is not an excuse for Debian Derivate Developers not to
co-operate with Debian Maintainers, or for us with our upstreams.
> And I like to point out that there isn't any correspondence between the
> ubuntu developers and the debian developers in respect to getting
> sensible patches they do back into debian, which very much disappoints
> me, if not does get me a bad opinion on the intentions of ubuntu.
Ubuntu (and other derivates) are using the same freedoms Debian
is built upon. We would not accept a licence that required us to submit
our patches upstream (dissident and desert island tests), so howcome it
is OK to require such behaviour from our downstreams?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 03:52:29AM -0800, Steve Langasek wrote: > On Wed, Feb 22, 2006 at 12:43:39PM +0100, Wouter Verhelst wrote: > > What makes 'running free windows drivers for stuff' so much more > > unrealistic than 'running free windows software for stuff'? Especially > > seen as how no Windows software is packaged for Debian, so that our > > users would have to do this themselves? > I can, personally, point to Free Software that I've run under Wine on > Debian. I can't do the same for free drivers running under ndiswrapper, and > I don't see that anyone else in this discussion has done so either. That > makes the second case a hypothetical, and IMHO it seems to be a contrived > one. Emulators/games have been moved[1] from contrib to main after someone has done free data files which are essentially "proof of concept" in nature. I fail to see why availability of a CIPE driver for ndiswrapper doesn't fall into the same category. A requirement for main "must be usefull in a free software only enviroinement" is the the beginning of the road to madness. Next theill come for free clients for protocols that (currently) only have non-free servers to connect to. Who the hell has the right to define what is usefull anyway? [1] sarien atleast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Sun, Mar 12, 2006 at 03:49:01PM +0100, Peter Kourzanov wrote: > Can anyone please explain why this architecture is named hurd-i386 > rather that i386-hurd? because dpkg-architecture has a line like this: return "$os-$cpu"; older dpkg (of sarge age) was more flexible, so likely the hurd naming decission was not done because of dpkg-architecture, but rather the other way around. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 10:38:52AM +0100, Pjotr Kourzanov wrote: > Wouter Verhelst wrote: > >Not being a dpkg maintainer, I find this to be a gratuitous change for > >no good reason (other than "it looks a bit better"). I don't see what > >point it would serve. > Maybe the ability to run Debian on embedded or old systems? > AFAIK, there is currently no support for running Debian with uclibc... Wouter is referring to the naming change. Indeed I agree, changing naming conventions is troublesome, and discussions about what naming convention "looks good" are endless. Essentially it's a "color of the bikeshed" [1] issue. As for debian with uClibc, there is SLIND[2] which uses uclibc-i386 / uclibc-arm/ uclibc-powerpc and i386-uclibc[3] alioth project, which is quite staganant ATM and hasn't selected arch name yet. [1] http://www.unixguide.net/freebsd/faq/16.19.shtml [2] http://www.emdebian.org/slind.html [3] http://alioth.debian.org/projects/i386-uclibc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
> >[2] http://www.emdebian.org/slind.html > This one looks dead. I understand we live in a gentoo-driven 0-day bleeding edge culture, but this is quite spectacular deducment. SLIND was published exactly two weeks ago in FOSDEM and it is already dead? >> ...and i386-uclibc[3] alioth project, which is quite staganant ATM >> and hasn't selected arch name yet. > >[3] http://alioth.debian.org/projects/i386-uclibc/ > There were no updates to this one since october. Is it still alive? I already said it was stagnant, please pay attention. I brought it into attention since it makes more sense to revive a old project than to start a completly new one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cross-compiling Debian packages
On Thu, Mar 09, 2006 at 10:24:58PM +0100, Peter Kourzanov wrote: > To continue the "./configure in debian/rules" thread... debian-devel is probably way too large audience, and will attract people not interested in crosscompiling/embedded on making unconstructive comments. lets move these threads to debian-embedded@lists.debian.org, ok? > Can anyone tell me what is the factual difference between a cross- and a > native-build? > I am aware only of an obvious limitation that a cross package build > system can not rely > on the cross-compiled binaries generated in the process (coreutils comes > readily as > an example)... This is not a limitation for scratchbox[1], using cpu transparency via sbrsh or qemu tests *can* be executed. Ofcourse, for i386-uclibc this is even less of a problem, as binaries can be executed without problem on the cpu as long as ld.so and other libs are expected places. Which brings us to the other problem scratchbox solves (shameless plug!!) Libary locations and library search paths. dpkg-cross and every other crosscompiling solution moves libraries to unexpected locations. You no longer can "just apt-get" the target arch libs you need. This is managable as long as you stick with autoconf -based software, but you'll go nuts with the more esoteric build systems, like the one of apache. Even with autoconfed apps, things like gtk and pango are not easy to crosscompile. Even then, modifying each and every debian package is a daunting process. It's easier to provide a crosscompiling solution that makes the applications not notice that they have been crosscompiled. This i what Nokia is using too ;) Inside scratchbox, the normal /lib, /usr/lib, and so on directories are filled with target arch libs and binaries, and apt-get install installs target arch pacakges. /scratchbox is then filled with host arch tools and crosscompilers. [1] http://www.scratchbox.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
On Tue, Apr 07, 1998 at 08:39:40PM -0700, Guy Maor wrote: > [EMAIL PROTECTED] (Gregory S. Stark) writes: > > Am I the only one who thinks the only correct prompts would be '$ ' and '# > > '? > > Barring that I suggest leaving the defaults, 'bash$' et. al. > You're not the only one. I also prefer to leave the defaults. > Any prompt in /etc/profile would be overridden by 99% of the users > anyway so what's the point? The point is new users. I can't imagine how it cuold hurt anyone to see where they are. It makes working a million times easier, if you can see all the time where you are. The first thing I allways do when installing debian to a friend is setting the the prompt in /etc/profile. Why should specifically make it hard for new users to get accustemed with Debian? Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
On Wed, Apr 08, 1998 at 11:06:44AM -0400, Raul Miller wrote: > Riku Voipio <[EMAIL PROTECTED]> wrote: > > The point is new users. > Then we should be talking about /etc/skel/, rather than /etc/profile The policy is to keep /etc/skel minimal, to avoid unecessary bloat of /home structure... keep in mind that many ISP's have thousands of users. Besides, what the diffrence if the configuration options are in /etc or /home/user ? And is there any single user who thinks that seeing the path is bad and can't change prompt himself? There are millions of new users who will not have a clue how to change the prompt and will just think that debian sucks, it doesn't even show where you are. Atleast this could make it to FAQ, but i can't possibly understand what damage is done if the default prompt is changed to PS1="\w\$ " . Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
On Thu, Apr 09, 1998 at 07:30:23PM +1000, Herbert Xu wrote: > In article <[EMAIL PROTECTED]> I wrote: > > make it to FAQ, but i can't possibly understand what damage is done if the > > default prompt is changed to PS1="\w\$ " . > Like that it won't work for anyone who uses a Bourne shell other than bash? Didn't think of it... Can we detect inside the script what shell is executing it? Then we could make it a condition that the prompt is set to something else if the shell is diffrent from /bin/bash... Ofcourse the right thing to do is a /etc/profile.d directory. Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
On Thu, Apr 09, 1998 at 08:36:33AM -0400, Raul Miller wrote: > Riku Voipio <[EMAIL PROTECTED]> wrote: > > The policy is to keep /etc/skel minimal, to avoid unecessary bloat of > > /home structure... keep in mind that many ISP's have thousands of users. > (3) Administrators, even administrators with thousands of users, can > administer /etc/skel/. Yes, but remeber that changes in /etc/skel affect only users that are added in the system _after_ the change. Exeisting users will still have old files. I still wonder, what it helps to put global configuration in user-specific files. Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
On Thu, Apr 09, 1998 at 11:42:30AM -0400, Raul Miller wrote: > Riku Voipio <[EMAIL PROTECTED]> wrote: > > Yes, but remeber that changes in /etc/skel affect only users that > > are added in the system _after_ the change. Exeisting users will > > still have old files. I still wonder, what it helps to put global > > configuration in user-specific files. > Then you're saying that the point is not so much new users but existing > users. Nooo... I mean those who new to linux in general and install it in their own computers. For them it doesn't matter if it is in the .bash_profile or in the /etc/profile. However, any large site admin will curse you to the lowest hell, if something is in every 20 000 users home dir what could be a single line in a single file. And if we ever decide to change /etc/skel stuff, it will only affect the users added after the change, and all previous users will be stuck with the old system. But if the change is done in /etc/profile, all users will be affected. Did I make myself clear? Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploaded timidity-patches 0.1-3 (source all) to master
On Thu, Apr 16, 1998 at 04:37:31AM +1000, Martin Mitchell wrote: > -BEGIN PGP SIGNED MESSAGE- > > Format: 1.5 > Date: Thu, 16 Apr 1998 02:20:12 +1000 > Source: timidity-patches > Binary: timidity-patches Uhh... Is the copyright surely clear? I remember that 4-front tech was nearly sued for distributing stuff only mentioned for GUS ownners... Riku Voipio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploaded timidity-patches 0.1-3 (source all) to master
On Fri, Apr 17, 1998 at 03:00:13AM +1000, Martin Mitchell wrote: > Riku Voipio <[EMAIL PROTECTED]> writes: > > > Source: timidity-patches > > Uhh... Is the copyright surely clear? I remember that 4-front tech was > > nearly sued for distributing stuff only mentioned for GUS ownners... > >From the copyright: > >From the README on archive.cs.umbc.edu: > 1) GUS instruments were freely obtained from anonymous ftp site: > archive.epas.utoronto.ca/pub/pc/ultrasound/gravis/disk So they were extracted from the GUS install disks packed on the net? Not everything avaible on anon ftp is free... Netscape comes in mind. If there isn't a specific mention that you can redistribute it, you are not allowed to redistribute it. And nowhere it is mentioned that you could modify anything, so this definetly doesn't go through DFSG... -- Joh 3:16 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /tmp exploits
On Mon, Apr 20, 1998 at 11:47:20PM -0700, Guy Maor wrote: > Modifying libc to catch common security goals is a laudable goal, but > such a libc should go to experimental. Why change libc? Isn't there a kernel patch that makes /tmp safe? Why isn't no-one using it? -- Joh 3:16 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ease of use and configurability
On Thu, Apr 30, 1998 at 03:13:52PM -0500, Branden Robinson wrote: > Every program that fetches user-modifiable files to control its behavior > (on a Debian system and according to the FHS, these should all be in /etc > or as dotfiles/dirs in $HOME) should have a kind an associated interface > file. Call it /usr/lib//gconfig or something. > Most configration files are reducible to key/value pairs (sometimes a key > word may take multiple values simultaneously, as in a list of pathnames), > or a list of grouped key/value pairs (/etc/passwd). > Pipe dream, or can we make it real? Or does this suffer from some horrible > conceptual flaw that I haven't thought of? I hope we can make it real. This is no.1 thing Linux needs to gain popularity. It really sucks that every app has a diffrent configuration system. > I must also say that I am sure I do not have the coding expertise to > implement much of this at all. If I did, I'd be on it. If I had more time, i'd try to implement it, even if i'm no expert. the only way to learn is to practise. Riku Voipio -- Joh 3:16 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
> > A much faster solution would be to use distcc or scratchbox for > > crosscompiling. > Debian packages cannot be reliably built with a cross-compiler, > because they very frequently need to execute the compiled binaries as > well as just compile them. Umm, that is the _exactly_ the problem scratchbox was written to solve. The idea is to have a chroot with crosscompiler and all the flex/bison/document generation/etc tools available as host binaries, while the actual libs linked against are as the target arch debian packages. When a binary actually needs to be run in the target arch, it is executed either with qemu or via sbrsh and nfs on a real target arch machine. As a consequence, most compilations are almost as fast crosscompiled as on the host machine. The ones that are still slow, are the ones that have a complex testsuite, like perl... The are a few drawbacks why it currently can't be really used as debian buildd: First, host tools are somewhat hacked versions of the same tools in debian. For proper debian usage, they should be the same versions as what has been last uploaded to debian. The other one is that the toolchains should also be generated from debian packages.. Currently the build process is kinda ad-hoc.. Incidentally the first problem should be solvable with the multiarch proposal, and the toolchains need to be polished anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: > In my opinon the root of the key differences is that with patch systems you > can have it both ways: > a) all chunks in one big diff > b) chunks clearly separated by issue > Obviously the patch system is an addition to the VCS, so one can live without > the underlaying VCS used in a given case. Huh? Storing patches on SCM is one of the issues that annoys *me* about having a patch system in addition to VCS. This blows also in the archeology sense. Comparing versions in VCS is harder when you are actually looking at diffs of diffs. > Seems like you will find clearly separated chunks useful sometimes. Yes, however the fact that we have almost a dozen of different patch systems (not including the package-specific NIH systems) pretty much negates any potential advantage. Having it either way, centralized SCM like Ubuntu or standardized patch system like RPM would so much rule over the complete lack of coherancy we have now.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Mon, Aug 14, 2006 at 04:09:33PM +0200, Joerg Schilling wrote: > This is of course a lie.or why don't you like to prove it: > http://cdrecord.berlios.de/old/private/problems.html > Come back to reallity, the k3b maintainers did already give up with > Debian versions of cdrtools and use self-compiled unmodified originalsources. This is of course a lie.or why don't you like to prove it? Neither upstream or debian packaging k3b includes "unmodified originalsources" of cdrtools, nor give instructions to users to use "unmodified sources". Come back to reality, stock Debian K3B burned just some minutes ago a fine bootable cd. *Thanks* to the patches in debian cdrtools that allows it to work with recent 2.6 kernels. But then again, we are probably in different realities anyway. Cheers, Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I want one of those!
On Fri, Aug 18, 2006 at 08:30:04AM +0200, Adrian von Bidder wrote: > Now I'm not a buildd operator nor do I have any experience on non-x86 > arches, but a 16 core MIPS 1U server that only pulls 50W power and that > ships with Debian preinstalled just has a very high coolness factor :-) > http://www.movidis.com/products/rev.asp Has anyone contacted movidis/cavium of getting this system supported in etch? It would make a nice bullet in etch release notes :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#360285: ITP: libjoey -- forks itself and does several things at the same time
On Sat, Apr 01, 2006 at 02:07:24AM +0200, Amaya wrote: > Steinar H. Gunderson wrote: > > I'd like the source for Joey, please. :-) > Formorer, please clarify with upstream, I have heard (today) that > libjoey is not 100% free, as in DFSG-free. In most legislations there are severe limits what you are allowed to do with libjoey and it's derived works. For example, various anti-slavery laws contradict directly with DFSG #1. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#360285: ITP: libjoey -- forks itself and does several things at the same time
On Sat, Apr 01, 2006 at 02:35:24PM +0300, Riku Voipio wrote: -snip- On a second thought, that was a bit too tasteless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages containing RFCs
On Friday 28 April 2006 13:34, Simon Josefsson wrote: > The following packages appear to contain IETF RFCs/drafts, and I'll > file bug reports for them: As per good mass filing practices, can you create a linda/lintian test out of your method you used to search for the rfc's ? This would have several advantages: 1) Active maintainers will fix the problem before you start your mass filing. 2) It will be harder to accidentally re-introduce the rfc files when upstream releases new tarballs, or when new packages are added to archive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote: > The package has bugs, lots of them, and for that reason has been removed > from testing, well done, unstable it is here for that. Uh no. I find it scary that you share this same idea as the original bacula maintainer. Unstable is NOT a graveyard for packages with RC bugs years old! While it is not uncommon to people to upload broken packages unstable, it's still not something unstable is meant for. And it certainly isn't ok just leave broken packages there.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 03:05:17PM +0300, Riku Voipio wrote: > On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote: > > The package has bugs, lots of them, and for that reason has been removed > > from testing, well done, unstable it is here for that. > > Uh no. I find it scary that you share this same idea as the original > bacula maintainer. Unstable is NOT a graveyard for packages with RC > bugs years old! Uh, I owe Jose a apology. The oldest RC bug was not RC for over a year, it was promoted to RC just recently. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Package Tracking System
On Mon, Jul 17, 2006 at 06:59:41PM -0300, Gustavo Franco wrote: > >Is an archive of those mails available somewhere? This way the "small > >patches" will be available even for packages of people not subscribed to > >the PTS. Or for people who subscribe after some version has been > >uploaded to ubuntu. > https://lists.ubuntu.com/archives/ubuntu-patches/ I think having those patches sorted by per-package would be more usefull. Thus there could be a link on the packages.qa.debian.org/source page to these patches. But this is a great start. Now we just need to pressure Linspire, Xandros and friends to produce similar feeds. (Or write a big-brother script to monitor them ;) Cheers, Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#379475: [Etch] Should sysfsutils be added to the base system?
On Tue, Jul 25, 2006 at 06:10:23PM +0200, Eduard Bloch wrote: > I disagree. You compare a 11kB utility (sysctl) with a new 132kB > package. You are comparing two completly different things. If we are to actually compare the size of tools actually *needed*: -rwxr-xr-x 1 root root 1554 2006-05-12 10:47 /etc/init.d/sysfsutils vs -rwxr-xr-x 1 root root 1244 2006-06-26 06:13 /etc/init.d/procps.sh -rwxr-xr-x 1 root root 9288 2006-06-29 03:08 /sbin/sysctl -rw-r--r-- 1 root root 48928 2006-06-29 03:08 /lib/libproc-3.2.7.so If you had bothered to read /etc/init.d/sysfsutils before starting the "bash the new and unknown" fest, you would see that it does not call systool and thus the package size or libsysfs2 size are not a problem. If we break sysfsutils initscript to another package, we have less bloat than what sysctl brings. Actually /proc/sys could be handled with the same script with trivial changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 07:54:27AM +, Lars Wirzenius wrote: > Chris Lawrence <[EMAIL PROTECTED]>: > > I suspect most people's MUA's don't display non-standard headers by default > > (I'm pretty sure mutt, pine, evolution, and elm as configured by default > > don't... and the lame copy of Eudora I'm using on vacation doesn't either > > unless you double-click on the message instead of using the preview > > pane). Perhaps if you put your request in your .sig people would read it... > There isn't even any need to put anything in the headers. From > Debian Developer's Reference, section 4.1 Mailing lists: > When replying to messages on the mailing list, please do not send > a carbon copy (CC) to the original poster unless they explicitly > request to be copied. Anyone who posts to a mailing list should read > it to see the responses. Which reminds me, why doesn't this list just set: reply-to: debian-devel@lists.debian.org Which most MUA's respect. Even this mail was one y from going only to liw :) -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 50 3313498 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. | pgpCCzZcAArbO.pgp Description: PGP signature
Re: Packages preventing other packages from going into testing
On Sun, Jun 15, 2003 at 06:44:12PM +0200, Jacob Hallén wrote: > Essentially, it is a count of packages that directly and indirectly depend on > a package with at least one RC bug before they can go into testing. > My idea is to show where the low hanging fruits are, so that people able to > lend a hand know where to go. While this is very nifty, unfortunatly just counting RC bugs doesn't track where real effort is needed. Take kdelibs as an example. When the RC bugs for kdelibs are fixed, kdelibs still can't goto testing, because all other kde applications have to be RC free and compile on all supported platforms. And since kdebase is creating internal compile errors from gcc-3.3 on mips/mipsel[1], there is not much sense raping buildd machines with builds that are bound to fail on some archs. And alas, there is not much one can do to fix gcc ICE bugs without knowledge of gcc internals. [1] 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194330' -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: debconf 2005 in Vienna, Austria
On Tue, Jul 29, 2003 at 02:43:50PM +0200, Javier Fernández-Sanguino Peña wrote: > Even if you are stepping in our idea of making it in Madrid, Vienna is > cool... I hope it's more cool than Oslo this summer was ;) -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. | pgpsW0Lxxa9kg.pgp Description: PGP signature
Re: debconf 2005 in Vienna, Austria
On Thu, Jul 31, 2003 at 11:25:24AM +0200, Oliver Kurth wrote: > On Thu, Jul 31, 2003 at 10:44:26AM +0200, Sven Luther wrote: > > But trains would be much more expensive, i think, than a common (full) > > bus. > Probably yes. Of course it depends on your preference, and what you can > afford. Traveling by train is much more relaxing, especially if you have > a bed there. Sort of, at least. Trains (atleast the newer ones in finland) have electric sockets, so we could headstart the debcamp. Maybe in 2005 there will even be 3G internet coverage on the route instead of the current max 50kbit/s gprs... -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: debconf 2005 in Vienna, Austria
On Fri, Aug 01, 2003 at 08:32:57AM +0200, Christian Perrier wrote: > This is still quite rare. For instance, in french trains (TGV and > "Teoz", formerly known as "Corail"ie Intercity trains), electric > wires are only available in the most recent coaches and only in 1st > class usually. > From memory, they are a little bit more common in Germany but not too > much and certainly not in all IC trains, especially 2nd class. IC2 trains in finland have electric sockets in 2nd class seats, As well as GSM repeaters. Older trains have electric sockets in the corridor, presumably not for public usage, but no sign forbidding to use them :) Night trains usually have a socket for shavers, which can be rather handy for charging purposes as well. A quick grep on bahn.de says that ICE-T trains (presumably the most expensive ones..) have power sockets for every seat. Anyone with experience on german/austrian railroad? > So, IMHO, you'd better have long life batteries.. :-) Yes. a debcamp of users would probably blow some fuse :) But still, using a laptop in a train is more comfortable than on a bus, or God forbid, on a car. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: libraries being removed from the archive
On Mon, Aug 04, 2003 at 04:28:49PM +0400, Nikita V. Youshchenko wrote: > > Guess how many hours it takes for the m68k > > buildd to rebuild kdegraphics. OVER 38 HOURS! > By the way, isn't it a good time to rise up a discussion about package > cross-compiling infrastructure? Isn't it good idea to research first before rising discussion? Just raising discussion without referring to any previous discussion about a subject is very counterproductive, as it inevitably leads to reitarating all the same arguments that where discussed last time. Try groups.google.com and keywords "autobuilder" "crosscompile" for a starter. Executive summary: Thus said Roman Hodek: > It's of course possible to cross-compile single packages where you > know that it works. But compiling *all* packages is a different thing. > configure too often makes problem, besides Makefiles that never > thought of cross-compiling... If you want to be productive, how about setting a buildd and trying to crosscompile the distribution and then post statsistics of failed/succeeded crosscompilings? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: libraries being removed from the archive
> > If you want to be productive, how about setting a buildd and trying to > > crosscompile the distribution and then post statsistics of > > failed/succeeded crosscompilings? > This is a good idea. Maybe I will try after my vacation. Is > documentation/hints abould how to do it available anywhere? THere have been some attempts to recompile the entire distribution on this list you may to search for. buildd is available at http://m68k.debian.org/buildd/getting.html . You will probably also be able to use pentium-builder package to trick the right compliler flags past the configure scripts. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: Please NMU dovecot
On Wed, Aug 06, 2003 at 11:18:18PM -0400, Jaldhar H. Vyas wrote: > On Tue, 5 Aug 2003, Jaldhar H. Vyas wrote: > > Could someone please NMU dovecot adding the patch in bug #203892? > > Either gcc 3.3.1 sucks or I'm having another hardware problem, > In case anyone cares, it was a gcc problem after all. Todays update works > perfectly. Sounds really odd. Maybe the previous gcc binaries you had where corrupted during your previous hardaware problems. I once got some really funky errors after running fsck on /usr with buggy ram. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 11:49:40PM +, Brian May wrote: > 2. All checks have to be automatic, and there is no chance of manual > review to ensure that the messages where geniune before bouncing it. Actually, I'm pretty sure SA is statistically better than an average person scanning subject lines of an unfiltered inbox. And if a real user gets his message bounced as spam, he/she has a chance to retry the message via some alternative transport, like POTS or snailmail, instead of getting the message buried in the reciepents spam folder. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver | pgpBxKSYrZ0ON.pgp Description: PGP signature
Re: vancouver revisited
On Sun, Aug 21, 2005 at 10:54:43PM +0200, Andreas Barth wrote: > * Peter 'p2' De Schrijver ([EMAIL PROTECTED]) [050821 22:39]: > > > - must have a working, tested installer > > Trivial. debootstrap does that. > How do you boot the system to run debootstrap? (Note: the answer > "gentoo" or "Windows" is not what I want to hear :) It is agreed that > this isn't a too high barrier, but - well, we should still require it. > If no (potential) port has an issue with that, it's even better. How do you boot to a system to run debian-installer when there is no bios or bootloader on the system yet? Should debian-installer support installing via JTAG? What happens on many embedded systems, debianish system is debootstrapped on a different machine and put into jffs2 image, which is then flashed to a pile of devices. Walking through d-i every time would be very clumsy, so there is no use for a working installer for those systems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vancouver revisited
Hi, > > How do you boot to a system to run debian-installer when there is no > > bios or bootloader on the system yet? > Just take a look at the existing Debian ports, and you see that it's ok > to use a bios that's part of the hardware. Eh, that was not what I asked. My point was, that there is no bios.. only empty flash. When you power it up, it will never ask for any kind of installation media. > > jffs2 image, which is then flashed to a pile of devices. Walking > > through d-i every time would be very clumsy, so there is no use > > for a working installer for those systems. > Do we speak about ports to architectures or machines? Machines and archs. On mips/mipsel/arm we have the situation that we support d-i on some legacy dead-end systems, while there is a pile new embedded systems on same arch. If you are working on the embedded side, it feels silly to maintain installer for machines you are not using, just for the sake of keeping the port in debian. On the worse side, there is archs like Axis cris/ SuperH, where pc-style machines have not really existed, an installer designed for installing desktops/servers does not make much sense. > If the sole > purpose is to be able to flash some embedded device, frankly speaking I > doubt that we need to host any *.deb-files on the ftp mirror network. Incidentally the awesome amount of precompiled binaries packages for esoteric archs Debian has, is the biggest (only?) advantage we have over other distributions in embedded space. Mirror space is irrelevant, having them available from a few mirrors would be just as good as propagating to all mirrors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vancouver revisited
Hi Joey, Your response was very much what I needed to hear. I'll have to retract most of my worries. On Mon, Aug 22, 2005 at 07:20:07PM -0400, Joey Hess wrote: > - A personal interest shared by me, tbm, and taggart is to get Debian >working on the various types of cheap mips wireless access points that >are now available in the < $100 price range, many of which now sport a >usb interface, so should be able to run a real Debian system. I imagine >it will be useful to have preinstalled images to load into the flash >and/or a USB drive, but that users will also find it useful to install >Debian on these from scratch using an installer they are comfortable >with from installing their PCs. I've tired using Debian on nfsroot/nbd on a Linksys wap54g. Unfortunatly I ran out of ram often, and swapping over nfs patches have disappeared into the time, while swapping over NBD gained some serious lockups.. An usb-slot seems to be necessary with current memory requirements of a fully featured distribution. As for using d-i, how do you envision it to happen in practice? Even getting a serial port requires soldering.. One way I see would be using fully automatic installs. A more nice way would be to be able to "cross-install" into creating preinstallable images on a faster host systems. > For what it's worth, when I look at the set of issues[1] that are blocking > us from releasing a new version of the installer right now, I see lots > to suggest that d-i will not be releasing again with support for all > Debian architectures anytime soon. Most of the issues are in the areas > of kernel, toolchain, and other basic tools, and many of them would cause > problems for anyone attempting the sort of debootstrapping you are > advocating. Unfortunatly debian wiki isn't talking to me atm, so I can't see what issues you are referring to :-/ Toolchain issues are important, as they affect everyone using the target, kernels are mor tricky.. Many vendors are happy when they have one working kernel for their stuff, and then never update it to match latest kernels.. Personally I would like to help on the arm stuff in debian generally, but I dont have arm systems here where debian-installer makes much sense for users.. Cheers, Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: spam in wiki.debian.net
On Tue, Sep 13, 2005 at 09:15:10AM +0200, Carlos Parra Camargo wrote: > The user "packceo" has been adding spam to the next pages of the wiki: ... > I've restored to the last revision all of them, is the first time that > happens? no, it was not the first time. see http://wiki.debian.net/?DealingWithSpam for instructions with dealing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: i386-uclibc debian
On Wednesday 28 September 2005 18:12, Daniel Ruoso wrote: > I'm interested in maintaining a i386-uclibc architecture, which is, like > the name says, i386 binaries linked with uClibc. My plans are: > 1) Build all the packages used by debootstrap to generate a basedebs.tgz > 2) Certify this basedebs works with a fresh instalation. > 3) Start building a incresing number of packages, but certainly only a > small subset of the i386 architecture. Similar thing was already done for woody, so you may not have to start from scratch: http://people.debian.org/~andersee/uwoody/ > The i386 packages won't be compatible with my i386-uclibc environment > (as I won't have glibc installed). So I started calling the architecture > i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it > OK? The naming might need some adjusting, and you may have to maintain it for quite a while under unofficial banner, but I think the idea is great. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely (Was: State of the project - input needed)
On Fri, Jan 25, 2008 at 09:59:00AM +0100, Pierre Habouzit wrote: > Oh and don't try to ask for complete uniformity in packaging, there > are 1000 DDs, 10 times as many packages We have managed to get almost complete uniformity of the binary packages produced. And imho, it's one of the things that makes Debian great. In this background it's kinda sad that our source packaging such a mess with so many competing and overlapping tools and SCM managment practices. Sure, the major problem that we dont's have a Tyrann [1] to choose, so people will prefer loudly what they are familiar with, rather than what is best. This means we need to find small evolutionary steps to get there, document best practices and eventually codify them. [1] http://keithp.com/blogs/Tyrannical_SCM_selection/ -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The meaning of Vcs-* fields
On Sat, Jan 26, 2008 at 01:00:51PM +0100, Cyril Brulebois wrote: > On 26/01/2008, Teemu Likonen wrote: > > About these new Vcs-* fields in debian/control: it's not clear to me > > where the URLs should be pointing at. > See for yourself: > | $ PAGER=cat man debcheckout | grep -A1 ^NAME > | NAME > |debcheckout - checkout the development repository of a Debian package I just tried this on madwifi, and it only pulled me contents of debian/ directory. Now I can't use that to anything, since there is no matching upstream sources available. I wonder if it would make sense to require that the Vcs- fields points to something that can actually be built. Now I have to go wandering where to get the matching upstream.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The meaning of Vcs-* fields
On Sat, Jan 26, 2008 at 08:37:54PM +0100, Stefano Zacchiroli wrote: > If I were you I would have tried "fakeroot debian/rules > get-orig-source", which is the policy mandated target to retrieve > orig.tar.gz. I haven't tried, but looking at madwifi's debian/rules it > is indeed implemented and retrieve the .orig.tar.gz. > mine maintained on svn work that way. This was a really usefull bit of information, thanks. Thou get-orig-source of madwifi pulls the source to ../tarballs so some manual work is still required. > If you are rather looking for a complete source tree as it will appear > in the archive then your only change is "apt-get source". And this again > does not surprise me, since such a source tree in the general case does > not exist for packages being worked on and not yet uploaded. It would be really nice if debcheckout would work like apt-get source. Maybe debcheckout could run get-orig-source if only debian/ directory appears under the checkout, or if the upstream version in debian/changelog is equal to the one available in apt sources, pull the orig.tar.gz there. -- "rm -rf" only sounds scary if you don't have backups signature.asc Description: Digital signature
Re: Introducing security hardening features for Lenny
On Tue, Jan 29, 2008 at 10:16:24PM +0100, Moritz Muehlenhoff wrote: > In kernels that support text ASLR, programs compiled > for PIE will gain full position randomization. For which architectures is text ASLR available? does it require external kernel patches? PIE means considerable system overhead and fatter binaries, especially for systems without large caches. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Wed, Jan 30, 2008 at 07:38:01PM +0100, Daniel Leidert wrote: > Am Mittwoch, den 30.01.2008, 12:31 -0500 schrieb Joey Hess: > > Because disk space is so much cheaper than your time that I can't even > > find the adjectives to describe how much cheaper it is? > My current workflow is fast enough. ..For your own packages. It's still a burden for you when you NMU other peoples packages or when people NMU your packages. > Upstream has its own VCS. So why to mirror it? Then we can directly go > to upstream and maintain our debian/* files inside their VCS. And this > is AFAIK not the easiest/fastest workflow. I can see that commiting to upstream VCS can be problematic if one does have a working enough relationship with your upstream to have commit access _and_ upstream uses a non-distributed VCS. Sadly this is a case quite often currently, but storing only packaging information in a separate SCM is workaround, not a solution for the abovementioned social and technical problems. The debian/ directory and the upstream sources are not really disconnected. especially if you look at it from the downstream distro (ubuntu, xandros, ... ) POV. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
On Sun, Feb 03, 2008 at 08:53:00PM +0100, Moritz Muehlenhoff wrote: > Did you followup with upstream on the SSP problems we've seen > on ARM? Basicly their response was basicly "why would anyone want 5-10% bigger and slower binaries on arm". It was also discussed the possibility of --disable-ssp we use on our current arm/armel toolchain being broken. Once I have a bit more time I'll try seeing what happens if you build gcc-4.3 with ssp enabled. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
On Thu, Feb 07, 2008 at 01:34:53PM +0900, Charles Plessy wrote: > I think that it is a bit frivolous to distribute software with > advertisment clause in main and not properly warning the redistributors, I think the short term solution to this dilemma is to compile a list of attributions needed to be included in advertizment material. Also a list should be compiled attributions needed n documentation (such as libjpeg's). Obviously most distributors/boob writers will not notice such lists, but that's a different problem... > Anyway, I really think that there are good chances to obtain a > relicencing, that is by far the best way to find a solution that > pleases everybody. This is even better, but it can pontially take a very long time. I believe it has bee requested from OpenSSL people years ago.. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: news from mips?
On Mon, Feb 11, 2008 at 12:08:13AM +0900, Charles Plessy wrote: > Sorry to be rude, but I am just so surprised that there is a such big > problem and that apparently nothing is done. If people are working on > the issue, just let us know, they will get many kudos and everybody will > be happy. In the absence of any communication, you know, there is the > usual frustration... I wonder - after a quick glance on debian-mips mailing list, it seems you _have_ been communicated on this issue: http://lists.debian.org/debian-mips/2008/02/msg00017.html You are even in the To: list of that mail... -- "rm -rf" only sounds scary if you don't have backups signature.asc Description: Digital signature
Re: Please allow the migration of the packages stalled in the MIPS buildd backlog.
On Sun, Mar 02, 2008 at 08:02:09PM +0900, Charles Plessy wrote: > Le Sun, Mar 02, 2008 at 10:56:19AM +0100, Julien BLACHE a écrit : > > In the MIPS case, the buildds are impacted by real technical problems > > that take time and effort to get fixed. > Exactly, and real technical problems mean real nuisance. > Dear Release managers, Dear Charles, the release managers *will* drop mips/mipsel/whatever from testing *when* it becomes a release blocking bottleneck. However with 463 RC bugs in testing, it is clear that dropping architectures is unlikely to make the release happen faster. If you want to positively influence the RM team to remove mips(el), the best way is to fix RC bugs. It will make the release happen faster, bringing the moment when RM team needs to choose what architectures are going to be released. It will also move you from the "whiners" group to the "doers" group, making it more likely that people act on your demands. signature.asc Description: Digital signature
Re: Bits from the armel porters
On Thu, Mar 06, 2008 at 11:39:24PM +0100, Frans Pop wrote: > Now that armel is becoming official, could someone involved with the port > please look at updating the info about the port on the website [1] in the > run-up to Lenny? Yeah, I sent a update for that page earlier, but it seems to have slipped from the radar. Resending.. > (Info for a lot of other ports could do with some updates as well.) The whole website needs more love. :( -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:34:36PM +, Ian Jackson wrote:
> Pierre Habouzit writes ("Re: dpkg semi-hijack - an announcement (also,
> triggers)"):
> > If you're so afraid that one of the included headers defines NULL to
> > '0', then just assert (__builtin_types_compatible(NULL, void *))
> > somewhere and be done with it. But please, (char *)0 is not only wrong,
> > it's also tasteless and ugly to the eye.
> In what way is (char*)0 wrong in these contexts ?
According to execlp manpage:
The list of arguments must be terminated by a NULL pointer,
and, since these are vari‐adic functions, this pointer _must_
be cast (char *) NULL.
--
"rm -rf" only sounds scary if you don't have backups
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On Sun, Mar 16, 2008 at 11:59:52PM +, Steve McIntyre wrote: > 3. For some arches, should we just provide the first couple of CDs > and a full set of DVDs? This is a bit of a compromise option - if > a given machine will not boot from DVD, but can boot from CD and > get the rest of its packages from a network share then all's good. With my arm(el) hat on, none of the arm devices we currently support boot from cdrom/dvd, so the main use of full DVD set is to help installations at offline/slow-internet sites. One needs very good imagination to imagine full set of arm/armel CD's being usefull to anyone. But CDs containing enough to install common tasksel tasks can be usefull for corner case where there is no DVD reader available but there is a cdrom drive. -- "rm -rf" only sounds scary if you don't have backups signature.asc Description: Digital signature
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
On Mon, Apr 21, 2008 at 10:36:37PM +1000, Mark Purcell wrote: > But you are free to assist with the package in what ever > way you can. All contributions are welcome. Patrick, as you see you are clearly welcome. So please cool down and submit patches :) > Perhaps in the longer term we could consolidate in a debian printing team, > http://lists.debian.org/debian-printing/ but given the amount of work > (outstanding BTS) each team has any contributions are welcome. Certainly, a package called "cupsddk" ending up maintained by hplip team is quite suprising.. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
On Fri, Apr 25, 2008 at 05:06:59PM +0200, Petter Reinholdtsen wrote: > 'arm' is said to be LE, but I believe it differ for integers and > floating point numbers. Is 'arm' in the list the 'arm' archtecture? > What about 'armel' and 'armeb'? on arm (unlike armeb and armel), doubles are two little-endian words stored bigendian. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SAGE packages for Debian
On Tue, May 06, 2008 at 02:44:04AM -0400, Timothy G Abbott wrote: > Packages with no problems worse than missing man pages: > python-arpack (from the scipy sandbox) > python-delaunay (from the scipy sandbox) I guess these can be handled by python-modules team that already maintains python-scipy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote: > Do you have a proposal for a remplacement of the glibc then? > And note we *do* forward patches we apply to the Debian Glibc, which is > not always something pleasant to do, especially when it concerns > "embedded crap" [1]: at best your patch is ignored, at worst you get > insults. Has using eglibc.org as upstream been considered? Forking is a valid option when upstream is as hostile and unco-operative as glibc's is. > That's why I personally don't want another level of administrative task > like proposed by Joey Hess, which won't improve things in that case. It seems very debian way - fix collaboration problems with policies and bureacracy.. I would propose that maintainers can suggest alternative collobarion models with upstream as well. Such as maintaing the delta against upstream in VCS branch of upstream, maintaining a policy that packager will only include patches that are already in committed upstream VCS, or extreme cases declaring that the debian packaging is a fork of upstream. -- "rm -rf" only sounds scary if you don't have backups signature.asc Description: Digital signature
Re: Debian's eboard package
On Mon, May 26, 2008 at 04:07:55PM +0200, Patrik Fimml wrote: > As I frequently use eboard and have done some "hobby" packages before, I'd > like to take care of the package. What exactly is the procedure to follow in > this case? I See you have already file for a ITA for this package, so you are on good track :) You'll probably want to work with debian-games[1] team for mentoring when getting started and getting eboard uploads sponsored. [1] http://wiki.debian.org/Games/Development -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dbus and initscripts
On Mon, Jun 02, 2008 at 07:34:22PM +0200, Wouter Verhelst wrote: > - On upgrade. Since apparently dbus-using services die when dbus itself > is restarted, it might make sense to restart those services too snip: text explaining one way to workaround the problem Howabout fixing dbus not to crash applications when restarting dbus on upgrade? irssi can pass it's sockets when upgrading to new binary (using the /upgrade command), so It's certainly possible implement in dbus too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#484009: removed bugs are marked as 'obsolete'
On Wed, Jun 04, 2008 at 02:31:22AM -0700, Mike Bird wrote: > (2) To a user who wishes to use a working feature of an imperfect > package, Debian is better with the imperfect package than > without: MISSING PACKAGE < IMPERFECT PACKAGE < PERFECT PACKAGE. > This is true even if the imperfect package has an avoidable > publicized security bug. ...for a certain subclass of _powerusers_ who are willing to walk through a minefield[1] using buggy software. For more typical endusers, buggy and unreliable software is a just big source of frustration. For the people willing to live the betaware life, there is still unstable out there. The potential damage caused by buggy software, atleast if the user hasn't made a conscious choice of using "beta" software, is massive. [1] One of the well known software antipatterns - The user learns a very specific route of clicks through the application will make it not crash, and the user will stick to that. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a project using cmake
On Sat, Jun 07, 2008 at 09:25:23PM +0200, Mathieu Malaterre wrote:
> >> $ superdupertool libfoo.so
> >>=> this lib requires libstdc++6 at least version 4.0.2
> > dpkg-shlibdeps run during build does that and then dpkg-gencontrol
> > replaces the ${shlibs:Depends} in control file
> All this is kindda new to me. When I was looking at debian package
> that use cmake to be build, I assumed the value in the control files
> where hardcoded.
You should read the Debian Policy[1] and Best Packaging Practices
from Delopers reference[2]. Else you will generate packages that
look superfically correct, but, are in fact buggy. IE don't develop
by guesswork.
[1] http://www.debian.org/doc/debian-policy/
[2]
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html
--
"rm -rf" only sounds scary if you don't have backups
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
On Mon, Jun 16, 2008 at 11:12:53AM -0400, David Duggins wrote: > I would also have to say that the Linux Community has always been about > freedom and choice. Not everyone agrees[1] about the choice part. Having one well working tool is better than having multiple mediocre, buggy tools to choose from. > Although I use GRUB my self, why should we remove a > useful package that is being used? Most importatly bacause LILO is lacking maintainence. When facing lack of manpower, something needs to be done. Eliminating duplicate functionality is one way to reduce maintainence burden without sacrificing overall set of features provided to endusers. As a bonus it allows making documentation shorter as you don't need to explain to new users which choice to select under which circumstances, it could allow making debian-installer simpler and thus more robust. The alternative is to find someone who will to fix the bugs in LILO. > GRUB and LILO fall into the category of Gnome vs. KDE > everybody has an opinion > on what they like best. It doesn't nessicarily mean that one is really > that much better than the other. It's not as black and white as you claim - removing LILO would not lead to the logical conclusion that we should drop gnome or KDE. There are many cases where having multiple choices is advantageous, cases of mediocre tools with superior alternatives and large grey and unclear area on between. Grub and Lilo do a simple well defined task. It's much more muddier for Desktop enviroinments, MTA's, editors or version managment software. Picking up the best one is hard, and dropping other doesn't make any sense when multiple of the tools are in active development and maintainence. Back to topic, I do not agree on the way Release team removed LILO from lenny without warning. It also seems that grub/grub2 is not really in any better condition than lilo - both have RC bugs... Cheers, Riku [1] http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html signature.asc Description: Digital signature
Bug#414737: ITP: scratchbox2 -- Transparent cross compiling environment
Package: wnpp Severity: wishlist Owner: Riku Voipio <[EMAIL PROTECTED]> * Package name: scratchbox2 Version : 0.0.1 Upstream Author : Lauri Leukkunen <[EMAIL PROTECTED]> * URL : http://rahina.org/sb2/ * License : LGPL Programming Lang: C, lua Description : Transparent cross compiling environment Scratchbox2 uses a LD_PRELOAD library to create a transparent cross compiling environment. Scratchbox2 automatically maps file system accesses to crosscompiler, target libraries and headers using a flexible lua path mapping engine. Together with CPU transparency, provided by qemu or sbrsh, scratchbox2 enables fast crosscompiling without modifying build scripts. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
> >> Many packages FTBFS (silently!) if an environment variable TAPE is set. > Perhaps dpkg-buildpackage should unset TAPE...? pbuilder and other tools already do that when chrooting? Tar's $TAPE behaviour fails the principle of least suprise. Tar developers should reconsider the usability implications of such feature. For packages, I think $TAPE is hardly the only environment variable that can change package outcome. Atleast the locale variables can wreck havoc for builds. Or consider setting AWKPATH or even PATH to something strange... Clearly packagers should not need to take care of all possible enviroment misconfigurations. That's why we tell people to use pbuilder. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
> > That's why we tell people to use pbuilder. > I think I disagree with the reason given for this advice. What > is the end goal that we are trying to achieve? Is it to upload binary > packages that build despite leaving flaws i the build process? Always > building in pbuilder masks errors like the $TAPE error; we would have > been better off having the build fail and be corrected. Why should we force 7000+ source packages clean their environment when debuild/pbuilder/sbuild etc will do that anyway? Worse, it's not even trivial to clean environment in a Makefile. Howabout documenting it as a fact that debian packages should be built in sanitized environment. > Me, I would try to build in pbuilder while I am trying to figure > out what the build dependencies are, and periodically on new upstream > to ensure the build dependencies have not shifted, but other times I > would build and test on my own machine, to more closely replicate the > environment that downstream users might have. As Dato already said, using debuild is enough. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian's Linux kernel continues to regress on freedom
On Wed, Sep 12, 2007 at 12:39:05AM -0400, Nathanael Nerode wrote: > Non-free material is being included in main for the benefit of *precisely > zero* > users. There's no two ways about this: this is a Social Contract violation. Kernel has 736[1] open bugs, including ones that corrupt data and make other packages fail to build. All but one affect actual users. Does the Social Contract really mandate that we should fix bugs affecting 0 users before dealing with bugs that actually degrade the user experience? If our priority really is users, we should fix those 735 bugreports first. And from the recent linux-2.6 uploads it seems that indeed kernel team gives priority to users. [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux-2.6 signature.asc Description: Digital signature
Re: Shared libraries, dependencies and symbols files
On Mon, Oct 01, 2007 at 05:47:34PM +0200, Raphael Hertzog wrote: > In other cases, most of the architectures are in sync and some > special architectures are creating troubles. It looks like > hurd-i386 is currently causing me lots of troubles for example on pango: > http://qa.debian.org/cgi-bin/mole/seedsymbols?pkgname=libpango1.0-0 Is it possible to compare this data against unofficial kfreebsd-(i386|amd64) and armel ports in http://ftp.gnuab.org/debian/ [1] ? Armel port is softfloat, and thus libraries using floats can end up exporting inlined softfloat math functions. As for kfreebsd and hurd, the differences in exported functions are probably produced by libtool.. -Riku [1] Faster mirror at http://ftp.de.debian.org/debian-kfreebsd -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 08:00:22PM +0200, Juliusz Chroboczek wrote: > While I realise that it is sometimes difficult to deal with hundreds > of old bug reports, there are other ways of dealing with this kind of > issue, such as tagging old bugs when they lack submitter input, or at > least going through old reports to check whether the information they > contain is useful. > I certainly did not expect this kind of approach from Debian. > > I would like to recommend > > http://www.jwz.org/doc/cadt.html If you feel more work should be done walking through old bugs, the best way is to work with the team in question. Free software is all about people scratching their own itches. If you can't find the time to triage old bugs, it's kinda hard to convince a volunteer to do it for you. Cheers, Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shared libraries, dependencies and symbols files
> > Is it possible to compare this data against unofficial kfreebsd-(i386|amd64) > > and armel ports in http://ftp.gnuab.org/debian/ [1] ? Armel port is > > softfloat, and thus libraries using floats can end up exporting > > inlined softfloat math functions. > Honestly, I have spent too much time on this project already and I'd > rather have some help instead of giving me more work... Fair enough. Do you have a todo-list where to pick up tasks from? > So while I could do it, I won't do it... Aurélien asked me to add support > for those arches in the listing above and I'll try to do it if Jeroen > manages to add support for those arches in Mole. That would be greatly appreceated. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Out-of-tree kernel module popularity
On Wed, Oct 24, 2007 at 11:32:26AM +1000, Paul Wise wrote: > Interestingly, Fedora has a new policy that kernel module packages > must be merged with kernel.org or removed from Fedora: > http://fedoraproject.org/wiki/Packaging/KernelModules > http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal > I don't think this would be an option for Debian, but it certainly is > a gutsy move. Very interesting. I'd say we should atleast consider it due to various points: Why we should follow Fedora -- + Out of kernel modules tend to be low quality. Either they lack the strict kernel community review, or they have failed the review and thus are sticking outside the mainline kernel. Do we want to expose users to buggy drivers? In kernel space there is lots of potential for data-loss and security bugs. Not to mention general system instability. + Out of kernel modules and patches get rapidly out of date Everytime kernel team updates the kernel, a bunch of kernel-module and kernel-patch packages break and need updating. This is big maintainence headache, and litters the RC bug list count. + Out of kernel modules are harder to use Even with m-a, it's still an bunch of extra steps over normal apt-get install. + The effort used in maintaining out of kernel modules could be used in something else. For example in cleaning and helping the driver upstream to submit the driver upstream. Why not... -- - Users will be unhappy with less "supported" hardware This may be deceptive. The users complaining that "ubuntu supported this hardware out of box" might have just left ubuntu due to stability problems. - Driver could be good, just the upstream is unjustfiedly refusing it Alternatively the Out-of-kernel module upstream might have whatever reasons why they want to keep their driver away from mainline. Not being a kernel developers, it might be hard to see if the module author or the kernel subsystem maintainer is right about the maturity/quality of the driver. In any case, this is more of a social than technical problem. maintining the driver out-of-free will merely allow to prolong the problem instead of solving it. The Exception to the rule: - non-free kernel modules. - Not mainlineble - ever - Any quality problems will just be a practical demonstration to users of disadvantages of nonfree code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Consistent handling of the DEB_BUILD_OPTIONS
On Tue, Nov 06, 2007 at 03:31:49PM +0100, Miriam Ruiz wrote: > 2007/11/6, Neil Williams <[EMAIL PROTECTED]>: > > There needs to be some agreement on what nocheck or notest means and > > which one to use. For Emdebian needs, whichever name is used, the > > imperative is that setting that DEB_BUILD_OPTION *must* completely > > prevent the execution of any compiled program within any test suite > > provided by upstream. The only checks or tests that can be implemented > > outside nocheck|notest must only use system binaries from coreutils, > > binutils-multiarch or one of the gcc binaries. > Some software packages, such as libcap, for example, seem to depend on > some code being autogenerated from a program executed in the target > (in this case, the generation of cap_names.h). As I see what Neil wrote, nocheck (I prefer this over notest) affects only testsuite. As for *handling* packages that run compiled code during build.. well that's the reason why scratchbox was invented :) -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#451560: ITP: sbrsh -- Scratchbox Remote Shell daemon
Package: wnpp Severity: wishlist Owner: Riku Voipio <[EMAIL PROTECTED]> * Package name: sbrsh Version : 1.4.1 Upstream Author : Timo Savola <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : GPL Programming Lang: C Description : Scratchbox Remote Shell daemon sbrsh requests a sbrshd host to mount a nfs partition, and executes a binary on it. This can be used to provide cpu transparency for cross-compiling with scratchbox. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.4 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#452014: ITP: atl2-source -- Source for the Attansic L2 ethernet driver
On Mon, Nov 19, 2007 at 03:47:35PM -0400, Ben Armstrong wrote: > * Package name: atl2-source > Version : 1.0.40.2 > Upstream Author : xiong huang <[EMAIL PROTECTED]> > * URL : > https://launchpad.net/ubuntu/hardy/+source/linux-ubuntu-modules-2.6.22/ > * License : GPL > Programming Lang: C > Description : Source for the Attansic L2 ethernet driver > This is the driver for the Attansic/Atheros L2 which is present in > systems such as the Asus Eee PC. Why not instead work on getting this driver into to the mainline linux kernel? Since the driver is GPL, the only reasons it's not in mainline are 1) The driver does not match the quality expectations of mainline linux kernel. In this case, out our quality expecations less than those of kernel? Are we really OK with shipping buggy and unreviewed drivers to endusers? 2) The driver is too new and isn't submitted to kernel yet. According to driver project[1], atl2 driver is "old and needs hacking". [1] http://www.linuxdriverproject.org/twiki/bin/view/Main/DriversNeeded#Fixed_Ethernet -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention
On Fri, Jan 04, 2008 at 11:26:21PM +0100, Josselin Mouette wrote: > I do hope there are better examples than a confidential application and > a useless daemon that has been deprecated for years, to justify messing > with dh_installinit and update-rc.d as you are proposing. You don't need to *hope*. You could just review your own /etc/init.d directory for scripts that do nothing nothing but "start-stop-daemon --stop" or something equal. looking at mine: anacron, atd, atftpd, dirmngr, hal, ... -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: recent spam to this list
On Thu, Oct 09, 2003 at 10:03:45PM +0200, Tollef Fog Heen wrote: > * Joel Baker > | Last I checked, this was (unfortunately) not yet an RFC, but only a draft > | proposal. It happens to be one I really like the idea of, but I am aware > | of more or less 'nobody' implementing it, nor any significant support for > | it in the major SMTP servers (though I'd love to have someone point out > | anything I'm missing, on that front...) Actually, It's worse. There is three[1] slightly diffrent proposals at the moment. There is work going on merging these proposals, so it definetly too early to adopt these proposals. The implementation in majos SMTP servers isn't that large problem, most mailers are modular enough these days to handle the problem with an external module. > I think it's a silly proposal, since it will hinder people like me who > are sending all their mail from a laptop to send their mail properly. And I think you didn't read the proposals and the discussion related to them at all. First hint: envelope from vs "^From: " Second hint: If you insist on your right to forge your email address, anyone else can forge your address as well. Is that a right you really need? Third hint: You can still choose to allow any IP send emails in your domains name. Just do not add the records in dns, and everything will stay as it is currently. The antipathy against the a POSSIBILITY of a domain owner to restrict sending mail in name of his own domain to few IP's is what is silly, not the proposal... > Of course, techies like we will find a way around it by tunnelling > mail through a ssh tunnel or the equivalent, but it'll suck for mobile > users in general. and most non-technical users will probably have one address and one SMPT AUTH based mail server to use. [1] http://spf.pobox.com/ http://www.danisch.de/work/security/antispam.html http://www.pan-am.ca/dmp/dmp-faq.html -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: recent spam to this list
On Sun, Oct 12, 2003 at 11:41:45PM +0200, Andreas Metzler wrote: > Julian Mehnle <[EMAIL PROTECTED]> wrote: > > Bernhard R. Link wrote: > >> * Riku Voipio <[EMAIL PROTECTED]> [031012 20:25]: > >> > Second hint: If you insist on your right to forge your email address, > >> > anyone else can forge your address as well. Is that a right you really > >> > need? > >> It's about to *use* an e-mail address, not about forging one... > > It's about forging an e-mail sender's identity. By preventing the > > unauthorized use of domains as the sender domain of e-mails, most of > > the practiced cases of identity forgery are prevented. > [...] > If I send an e-mail over mail.nusrf.at with envelope-from > [EMAIL PROTECTED] I am _not_ forging anything or making > "unauthorized use of domains" Effectively you are claiming to send from [EMAIL PROTECTED] while the truth is the real sender was [EMAIL PROTECTED] - in this case it just happens that the identity behind both is same. The owners of logic.univie.ac.at are free setup any policy in SPF they want. If they think that there is no reason to protect unauthorisized use of their domain, they can choose to setup and wildcard and allow any IP in the world to send mails using logic.univie.ac.at domain. What is your problem with that setup? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: recent spam to this list
On Mon, Oct 13, 2003 at 12:34:46AM +0200, Tollef Fog Heen wrote: > * Riku Voipio > I have mail-followup-set for a reason. In addition, it is normal > policy on Debian lists not to Cc people unless explicitly requested. Hmm. my mutt setup appears to be b0rken then. sorry about that. need to look that. > I don't want my bounces to go to the wrong place. I don't have root > at all the places I send mail from, nor do I trust all those who have > root there. So, I don't want my mail bounced to the wrong place. So then use a envelope-from from a domain you trust? You said that you use a specific relay to relay your mail already, so you could setup your domain (raw.no) so that only that specific IP is allowed to send mail to the world using raw.no domain? You can still put your university address in the "From: " field like you do right now. > | Second hint: If you insist on your right to forge your email address, > | anyone else can forge your address as well. Is that a right you really > | need? > Uhm, how would you forge your own mail address? It's like forging > your own signature, something which is, by definition not possible: To quote dark: A bad analogy is like an leaky screwdriver. If you have two IP's, one at home ISP and another at work, and you send packets from your home IP using the work IP, you are forging the sender IP, even if you happen to be affiliated with both IP's. > No, I can't. I don't control the DNS of my University, a few of my > ISPs and so on. Nor do I control Debian's DNS. And you don't need to, unless you want to send your bounces to your university or debian servers. Why would you want to do that? One could also argue, that since the university/debian owns the domain, they can setup whatever policy they want on what IP's can send mail in the name of their domain. Lots of opposers seem to assume that domain owners will immediately apply an policy that will force senders to use their mail relays for outgoing mail, without consulting their users first. > | The antipathy against the a POSSIBILITY of a domain owner to restrict > | sending mail in name of his own domain to few IP's is what is silly, > | not the proposal... > It's the wrong solution. And what is the right solution? One that even the blondes using hotmail can use? Just accept it as fact of life that viruses and spam use every now and then your domains? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: gimp1.2: gimp package suggest non-free software
On Wed, Nov 12, 2003 at 12:10:02PM +0100, Mathieu Roy wrote: > Apparently you forget about a specific part of the Social Contract. > (Our Priorities are Our Users and Free Software...) I have a creepy feeling that you are not wearing a user hat but rather a hat of an organisation with a specific agenda. The current compromise of splitting gimp/gimp-nonfree is not ideal, but it's temporary measure anyway.. > > . And given that you appear to have a religious objection > Does this assertion have any ground? Nobody but a religous nut would claim that providing a Suggests: link to software that is free (except for some parts of world) is evil. > Sure, keep lowering the quality of Debian in matter of freedom, > there's no matter discussing that. Sure, keep lowering the quality of debian-devel mailing list in matter or signal/noise ratio, If everyone of the 1784 list members used 1 minute reading your rants, we've just lost 4 workdays of creating a better debian. Please provide patches, not flames. Some contructive suggestions: 1) Eat some icecream and cool down. 2) Just wait until dust settles around lzw. 3) Add non-lzw gif saving support to gimp. 4) Patch apt-listchanges so that id doesn't mail about suggestions on packages that are not available. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: Are we losing users to Gentoo?
On Mon, Nov 25, 2002 at 06:56:57PM +0100, Jose Carlos Garcia Sogo wrote: > > It must said that comparing Gentoo with Debian in this > > regard is unfair as they are not like for like, being > > source against binary package. That said some things > > (X 4.2 springs to mind) take far too long to make it > > to testing. > Could you run X 4.2 in, say, s390 that date? FYI, X is supported in 11 > archs in Debian, a lot more than upstream supports. So, debian is coming the netbsd of Linuxes.. Sure a novel goal to support rare hardware, but why does ot have to come at the expense of commodity hardware owners? even worse, that date you could have a working X (4.1) in s390 but not in a x86 laptop.. or a radeon desktop (not sure, but if I remeber correct, 8500 support came in 4.2). > If you want to compile things because that makes fun to you, you can do. > Some people in Debian does that from time to time and fills FTBFS bugs > on packages. Perhaps you could help them. I would believe that most packages build fine from source. However, trying to push yuor own compiler optimisations can be rather hard.. DEB_BUILD_OPTIONS is still just a recommondation in the options, and doesn't support aggressive optimisations.. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: Are we losing users to Gentoo?
On Tue, Nov 26, 2002 at 03:07:47PM +1000, Anthony Towns wrote: > On Mon, Nov 25, 2002 at 07:46:20PM -0800, Brian Nelson wrote: > > Debian's support for so many arches slows down development in other > > areas as well. For example, getting gcc-3.2 working on all arches has [...] > the key issue. We have one outstanding issue with gcc-3.2 at the moment, > which is that cmath on sparc doesn't work. Something is seriously wrong, if a single bug that affects a single arch can stop everyone else from forward. We need a way to get packages that are broken on some platform into the distrubution while the developers of the arch sort out the problem. Not the way it is happening currently, that everyone has to wait the platform to fix itself before updated packages get into distribution. Maybe we should start the gcc-3.2 migration now, and just not autocompile c++ apps on sparc until gcc is fixed? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: i386 compatibility & libstdc++
On Saturday 26 April 2003 05:08, Chris Cheney wrote: > On Sat, Apr 26, 2003 at 09:36:56AM +0800, Cameron Patrick wrote: > > What about the Via C3? That was introduced not too long ago, runs > > moderately quickly (~1GHz) with low power consumption, but IIRC doesn't > > support the i686 instruction set. > The issue with this appears to be a gcc bug with respect to compiling > for i686: > http://marc.theaimsgroup.com/?l=linux-kernel&m=104263370505476&w=2 Considering cmov optional for i686 seems odd. The only major new operand added from i586->i686 was cmov. In most cases using cmov is a HUGE win because you avoid branching. Even as a owner of a C3 cpu, I would leave C3 on the other side of the fence, slowing down 99% of Athlon/PII users for the sake of 1% of C3 users doesn't make sense.
Re: bind9-chroot (was: questions on ITP)
On Tue, Sep 25, 2001 at 04:34:31PM +0200, Christian Kurz wrote: > On 01-09-25 Steve Greenland wrote: > > I am so tired of hearing things like this. Nobody is forcing anyone to > > do anything. We already "force" them to use 2.2 instead of still using > > 2.0. You want the functionality, you use the right tools. You want to > > Were exactly do we force them? Which debian packages do not work well > with a 2.0.x kernel? apt-cache search usb for example. > > stick with 2.2, then *you* deal with the issues. The maintainers have > That's a nice attitude, which will lead to the situation that > people, especially administrators, will move away from debian to either > other distributions, a bsd flavour or other free operating systems. Forcing new users to deal with historic burden is not an answer. Use a old kernel - loose features. I really can't understand your problem with limiting chroot bind9 feature to kernels with --bind mounts support. They still can run bind9 perfectly, although less securely. If 2.2 kernel users want chrooted bind, they a) have already done it - no extra work b) upgrade to 2.4 - sheez, that was hard... c) do it manually - no more work than it is now who the hell has to do more work, if we add *support* for *automaticly* running bind9 in chroot jail if the kernel supports --bind mounts? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: XFree 4.2.0 - again
On Tue, Apr 16, 2002 at 06:28:50AM +0300, Lasse Karkkainen wrote: > What comes to encouraging other people - guess what I'm doing right now. No you are definetly not. You are pissing people off. > Other platforms aren't nearly as significant as i386 (not many users, no > much new hardware). You're arrogance makes me wonder if George W. Bush is related to you. I'll give you a hint: we are volunteers, and we do this because it's fun. Messages like yours, that demand service for free just disgust. I guess after seeing your messages Branden goes out for a beer rather an opens a editor to serve ungrateful kids. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libpoppler3 missing in unstable
On Wed, Mar 11, 2009 at 12:55:52PM +0100, Adeodato Simó wrote: > The problem is, of course, defining the “well-defined policy”. For most > libraries an early removal has no big consequences. It would have been > tempting to have guessed that there wouldn’t be any for poppler either, > because the fact that decrufting poppler would render texlive uninstallable, > upon which a lot of packages build-depend on, needs a bit of close looking > in order to be noticed. IMHO the root cause here was that the poppler transition required source changes in the reverse dependencies (such as texlive-bin). Yet, the maintainers of poppler didn't care to warn maintainers of reverse dependecies nor the release team that this transition isn't solvable with just binNMU's. This lead to the transition to take so long that old poppler library got decrufted. Perhaps it should be assumed by default that soname transitions require source changes, _unless_ proven otherwise. And proving is really simple - just try recompiling all reverse dependencies against the new library. signature.asc Description: Digital signature
Re: ARM hardware available for developers
On Tue, Mar 17, 2009 at 08:05:50PM +0100, Martin Michlmayr wrote: > I have a number of ARM devices/boards that I no longer need and I'm > looking for developers or testers who can do something useful with > them. Those devices have been given to me to improve Debian support, > and so they should be used for Debian related activities > (debian-installer tests and development, kernel work, or other things > you can think of). In a similar tune, I have the following gear to offer: - 1x Allnet ALL6500 (Thecus N2100) - 1x Kurobox HG (266Mhz powerpc) - 1x IO-Data lan tank (266Mhz superH) All of them have a serial port available. > Since I somehow have to get the hardware to you, I'd prefer to hear > from people in Europe or the US but this is no absolute requirement. > Note that none of these devices come with hard drives. > If you're interested, please contact me privately and tell me the > following information: > - What you would like to do with the device - if you don't clearly >show that you'll do something useful with the device, you definitely >won't get it. People who will actively contribute to Debian's ARM >port get bonus points. > - What kind of experience you have. > - Is there one device you'd prefer? > - Where are you located? Same instructions. If you are coming to debconf this yead, it doesn't matter where you are located. > If I decide to send you a device, the following rule applies: this > device is to be used for Debian related work. If you no longer have > the time or interest in doing something useful with the device, it's > your obligation to find another person who will do something useful > (and Debian related) with it and give it to them. The ALLNET was donated for debian work, the rest are more flexibly available for any kind of free software work. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packaging ltp selinux tests
On Mon, Apr 06, 2009 at 10:13:39PM -, Jiri Palecek wrote: > I'd like to package the selinux tests from the ltp test suite. The tests > need a special selinux policy to be loaded and some files to be relabeled. > I haven't found any standard way of packaging this, so I made an > experimental package (see [1]; it sort of works - not completely, like 10 > tests out of 30, but that's not an issue now) and I would like to hear your > opinion on these issues: > 1. The package loads the policy on "postinst configure" with semodule -i, is > that right? (And did I implement it properly in the scripts?) There were some > avc message during package install (semodule was denied access to a terminal > with type apt_t), can this be solved? As long as it fails gracefully is semodule binary is missing or selinux isn't enabled. > 2. The relabeling has to be done manually with fixfiles relabel; is there a > way to do it (and should it be done) automatically? > 3. The runtime packages depend on selinux-policy-default; should it > (alternatively) depend on the other policies too? Would this need a separate > policy package? > 4. Should the policy package be in /usr/share? I didn't hear any comments for one month on debian-devel, perhaps our selinux masters Russell or Manoj have a word to say? If there still isn't any opinion, I will work on sponsoring the ltp package with selinux tests on weekend. Cheers, Riku > [1]: http://mentors.debian.net/debian/pool/main/l/ltp/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: architecture wildcards, type-handling, etc.
On Thu, May 14, 2009 at 10:13:43AM +0300, Peter Eisentraut wrote: > On Wednesday 13 May 2009 21:55:00 Guillem Jover wrote: > > So, there's missing support in sbuild (#501230), which arguably is > > a pretty recent bug report, but AFAIR I sent a mail to Ryan long time > > ago when drafting the wildcard support and never heard back, but then > > I never insisted again, so that's on me. > > > > Then the buildd network will need to be upgraded to use an sbuild > > supporting that. I'm not sure if wanna-build might also need changes. > > Lintian will need to be fixed as well once the buildd network supports > > this. And then minor stuff like the vim debcontrol syntax highlighter > > and similar. > Would it be reasonable/acceptable to establish this issue as a squeeze > release > goal? a release goal is IMHO something that needs fixes in a sweep of packages in archive before release. This change OTOH just needs fixes to sbuild and then some infrastructure work (deploying new sbuild/buildd everywhere). As the second part is already being worked on, all you need is to provide patches to the sbuild/buildd maintainers :) signature.asc Description: Digital signature
Re: say goodbye to network-manager-strongswan?
On Wed, Jul 16, 2014 at 01:05:26PM +0200, Harald Dunkel wrote: > Hi Thijs, > On 07/16/14 12:35, Thijs Kinkhorst wrote: > > As it turns out, this package got removed because it has an unfixed > > release critical bug (which interestingly enough you yourself reported). > > When this bug is fixed, the package will transition back to testing. > Of course I know that I reported this bug (without "grave"). > Did you notice that the bug report also shows how to _fix_ > the problem? This a side-effect from Debian's policy that discourages fixing bugs in other maintainers packages via NMUs. Somehow, it is felt better to remove packages from testing than possibly offending the maintainer with an unwarranted NMU. Since you seem to know the software well, and it is important for you, perhaps you can take over maintainence of the package? The current maintainer doesn't seem to be active (no upload since 2012..). Alternatively the package could be maintained by the strongswan team? Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140716124013.ga7...@afflict.kos.to
Re: systemd service and /etc/default/
On Sun, Aug 17, 2014 at 01:13:36PM +0200, Marc Haber wrote: > On Sun, 17 Aug 2014 01:40:27 -0700, Josh Triplett > wrote: > >Ludovico Cavedon wrote: > >> I am writing a systemd service file for a daemon (ntopng) and I would > >> like to know what you think is the best way to load some > >> configuration. > >> > >> The ntopng daemon takes multiple interfaces in the format of multiple > >> -i command-line options. For example. > >> ntopng -i eth0 -i wlan0 > >> > >> Currently the interfaces are stored in /etc/default/ntopng > >> INTERFACES="eth0 wlan0" > >> > >> and the sysv init script takes care of adding "-i" for each one of them. > >> > >> I would like to keep the sysv compatibility and do the same in systemd. > >> > >> I tried in various ways, but the two solution I could think of are: > >> 1) change the format of INTERFACES to require inclusion of -i. > >> I.e > >> INTERFACES="-i eth0 -i wlan0" > >> and use EnvironmentFIle=/etc/default/ntopng. This changes the format, > >> complicated upgrades, and is more error prone. > >> 2) instead of doing Exec=ntopng, Exec a script that does the mangling > >> and then execs ntopng. > >> > >> Because both solutions do not look great to me, and I could not find > >> an example, I am asking your opinion. > >> > >> After writing this email, I start to believe 2) is the right way, but > >> I would appreciate anybody's input. > > > >3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the > >settings there. > >4) Teach ntopng to automatically detect the available network devices on > >the system (including new ones that show up dynamically) and > >automatically handle all of them unless configured to do otherwise, > >making configuration usually unnecessary. > Please. The attitute of requiring Debian maintainers to modify > upstream software instead of having simple two-line extension to an > init script is really unfriendly. Why do only systemd friends keep > recommending this? Once upon time, every distribution carried scripts to autodetect and build a XF86Config for end users. Every distribution duplicated the effort for their own scripts, each had different bugs and limitations. Some even made a selling point of having better autodetection than other distributions. Then upstream added autodection.. ..and pretty much all that duplicated work became wasted. Making upstream software better is for the benefit of all users. Making debian specific scripts (and patches) are only the benefit of debian users. Doing a few lines in initscript/postinst saves the Debian maintainer time, but only in the short term - If the upstream changes cli options, configuration files etc - the debian maintainer will have to spend time adapting. Worse, the maintainer may have to write new scripts to migrate setting from old format to new. The more scripts you wrap around the upstream codebase, the maintaince burden you have in future. This is the position where the ntop maintainer has found himself in (except it is not upstream, but another tool that has changed). Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818104413.ga15...@afflict.kos.to
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
Hi Henrique, On Wed, Sep 24, 2014 at 03:18:02PM -0300, Henrique de Moraes Holschuh wrote: > OTOH, using -z9 on datasets smaller than the -z8 dictionary size *is* a > waste of memory (I don't know about cpu time, and xz(1) doesn't say anything > on that matter). The same goes for -z8 and datasets smaller than -z7 > dictionary size, and so on. > It is rather annoying that xz is not smart enough to detect this and > downgrade the -z level when it is given a seekable file (which it can stat() > and know the full size of beforehand). This wouldn't seem too hard to implement in xz - have you asked upstream about it? Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925095914.ga4...@afflict.kos.to
Re: debootstrap and cdebootstrap vs systemd
On Fri, Nov 07, 2014 at 10:00:38AM +0100, Thorsten Glaser wrote: > On Fri, 7 Nov 2014, Adam Borowski wrote: > > > You can chroot to the system from the host machine, and upgrade to sysvinit. > > If your host can't run arm code, install qemu-user-static and copy > > /usr/bin/qemu-arm-static to the target system. > > This is no fix. There are systems Qemu does not emulate. But afaik all debian archs are? From the ports side qemu doesn't do hppa, and m68k and sparc64 are probably buggy. Nothing unfixable, just that nobody has cared enought to get them fixed :) And for not-even-in-ports architectures debootstrap is not really relevant. > debootstrap --include and --exclude should work. Yes of course. If not there could be a --variant=sysvinit, but clearly it should be possible to debootstrap without systemd. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107104029.ga13...@afflict.kos.to
Re: debootstrap and cdebootstrap vs systemd
On Fri, Nov 07, 2014 at 08:30:32PM +1100, csir...@yahoo.com.au wrote: > "Don't accept old kernels" is almost equivalent to telling many > unrelated businesses in a particular ecosystem to burn their > investments and start again from scratch, just because the SoC and/or > board vendors have a broken business model. And that's hard to explain > to business people and even hardware engineers that a > chip/board/subsystem is "unsupported" even though supply guarantees > stretch out to the year 2020 and beyond. If you choose an old Soc vendor kernel, you effectively choose to use old userland from the same era. Better do your business plan based on it: "we won't upgrade userspace except for backported critical fixes and features we REALLY need" And it probably not that bad deal anyways. Instead wondering how to adapt your existing working code to new userland (say initscripts to systemd), your engineers can spend time working on something that actually matters to your customers. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107111829.gb13...@afflict.kos.to
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 02:19:41PM +0100, Florian Lohoff wrote: > I meanwhile see the systemd issue as a social problem within debian. There are > design issues which are REALLY controversial. In the past Debian did good by > delaying adoption of controversial technical issues e.g. devfs and waited in a > conservative way until dust settled and there was roughly a consensus. > Sometimes this lead to better approaches to see the light e.g. udev. > This has changed - Debian has changed. > It seems we need to rush in all interesting stuff without looking forward > past > some months - Today systemd might be THE solution to some peoples problems. > Is it > tomorrow? I doubt it. Uhm, systemd was uploaded to debian first in 2010. Are you saying 4 years is too much of a rush? What would be your view of a reasonable schedule? Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113133432.ga20...@afflict.kos.to
Re: switching from exim to postfix
On Sat, Apr 28, 2012 at 07:12:42PM -0700, Russ Allbery wrote: > I'm not sure that I see the point, and I say that as someone who > replaces Exim with Postfix on all of my boxes. Nobody's suggesting you need to change to anything. The worst you have to do if debian changed default MTA, would be to "apt-get install exim4" (gasp, what horrible pain) when doing new installations. > There's nothing particularly wrong with Exim; it works just fine. Exim in 2012 not supporting 8BITMIME and thus being the last Major MTA forcing quoted-printable conversions to make emails "7bit clean" is quite horribly wrong. Debian is the main source of Exim installs in internet, it is also our fault. According to one old stat[1], 34% of mx records were exim, most probably almost all simply because it came by default in debian and it was "good enough" so people didnt' switch away from it. So yes, switching to postfix by default would reduce the workload of email servers around the globe (no need to burn cpu cycles and thus co2 to convert emails to quoted-printable). Yes that was a bit of a hyperbole, but this is my pet issue. I complained last about it in 2009 [2] with no change from upstream since... Riku [1] http://www.securityspace.com/s_survey/data/man.201007/mxsurvey.html [2] http://suihkulokki.blogspot.com/2009/07/cult-of-workarounds.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120430101419.ga30...@afflict.kos.to
Re: switching from exim to postfix
On Tue, May 01, 2012 at 12:48:10AM -0400, Chris Knadle wrote: > I think it would be useful to describe what issue(s) there are concerning > 8BITMIME and why this is important. I've found some information [1] about > this, but it isn't clear what problems are actially *caused* by the lack of > 8BITMIME support by default in Exim. Is it just slow sending of outbound > attachments? It's both extra traffic (not that much if western encodings) and extra cpu work. In lesser annoyance, it means that you no longer can read mailbox files with non-mime capable readers (for example less) with ease, as there will be qp encodings here and there. People who only use english only hit the issue when having lines longer than 76 characters. Basicly that the qmail author is suggesting is violating the rfc by announcing 8bitmime sopport but never doing any conversions if you bump into a server that doesn't support 8bitmime. This is the same as the exim's accept_8bitmime option. In the real world, violating the rfc is a non-issue, as most likely the only non-8bitmime compliant servers your server encouters are qmail and exim4, both which have no problems with 8bit mails itself. Honesstly. my grievance is really just having to convert things to 7bit.. still! > The quoted 2010 survey [2] showed Exim was the most popular MTA (which I > found > surprising), deployment of Exim growing just slightly faster than Postfix, > and > everything else falling in popularity. I think it is because other distro's have mostly stopped shipping anything that listens on port 25 by default. > I don't know how one would verify (or dispute) the claim that Debian was the > main source of Exim installs Indeed that is not verifiable from the given report. However, they list the most common exim version being 4.69 which is same as what was in lenny at that time. > > So yes, switching to postfix by default would reduce the workload of email > > servers around the globe (no need to burn cpu cycles and thus co2 to > > convert emails to quoted-printable). > The statistics quoted showed that Exim was most popular, so wouldn't > switching > to Postfix by default actually be more CPU costly than the reverse? :-/ > [I'm > not saying you're wrong, just that I don't see the logic in the argument.] The less there are MTA's out there not announcing 8bitmime, the less conversions there will be (eventually). While the exim->exim deliveries are not generating conversions (unless the MUA does it), exim is still only at 34% of mx, not 34% of the traffic. > I've likewise often wondered if a low-resource MTA like DMA or ssmtp could be > the default MTA for Desktop installs (and I've occasionally tried them), but > as has been discussed there seem to be some issues with the idea. In my case > for Desktops I want the local MTA to be able to handle sending local outbound > mail to a server via port 587 over TLS with authentication, to retry sending > at increasing time intervals, using a "queue runner" but without a daemon > listening, and to notify the sender on a permanent failure. Thusfar I've > only > been able to find all of that in a full-fledged MTA. Indeed, switching to a lightweight mta like dma as default makes probably more sense than switching by default postfix. I tried ssmpt and it didn't work for me.. Would dma do TLS auth and queque fine? Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501155520.ga6...@afflict.kos.to
Re: switching from exim to postfix
On Tue, May 01, 2012 at 08:18:07PM +0200, Philipp Kern wrote: > So just stop Postfix doing the conversion? It's not just postfix, it's at least courier and sendmail and various propiertary MTA's do conversions when encountering default configured exims. It would be a RFC violation to just pass 8bit mails to servers not advertizing 8bitmime. It would be rfc compatible to the sending server to bounce instead of qp-converting 8bit mails, but that would arguably be even worse. > Or teach Exim to announce 8BITMIME by default. That would be a rfc violation as well. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502082913.ga15...@afflict.kos.to
Re: Making -devel discussions more viable (was: switching from exim to postfix)
On Thu, May 03, 2012 at 01:23:29PM +0200, Stefano Zacchiroli wrote: > 3) public, but contributors-only list > This has been implemented by other FOSS projects. A notable example is > Ubuntu who have a split between ubuntu-devel (project members only + > whitelisting) and ubuntu-devel-discuss (free for all). I've never asked, > but I have always suspected that they've done so in an attempt to > improve over the experience of debian-devel participants. > The obvious drawback of this "solution" is that non-contributors will > need someone to vouch for them to be whitelisted. How about a "automated" contributors-only list. To post to debian-devel, one would have to either submit a patch to a bug, close a rt ticket, commit to one of the scm.debian.org or upload a package to debian. You include a url to that in the footer of the mail, and the mailing list checks that it was really your change and it was done recently. The check does not need to be perfect, if someone tries to cheat the check we just ban the user for a while. Non-contributors out of blue can still engage in the discussion, they just need to contribute something first :) We enough "easy" jobs from manpage writing to translations that the rule would not prevent anyone who wants help debian to voicing their opinion. One just needs to get out of their email client and actually do something useful for a change. It could also lessen the instant-flame-reply culture, as you would have to do something else before replying - probably causing you to cool down and articulate a better answer. Before you scream "that's a technical solution to social problem", I find it rather an economical solution to a social problem. Debian has something people want (to voice the opinion) and Debian needs something they can do (fix bugs). The solution brings them together. Riku For example, this mail would have been bought to you by the courtesy of: http://incoming.debian.org/mtd-utils_1.4.9-1.dsc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503140438.ga22...@afflict.kos.to
Re: switching from exim to postfix
On Mon, May 07, 2012 at 02:33:54PM +0100, Adam D. Barratt wrote: > fwiw, there's just (as in within the past couple of hours) been a change > committed upstream which defaults accept_8bitmime to true. Good news. As mentioned on bug #445013: -snip- > accept_8bitmime = true > I would actually recommend setting this to true by default, since it > no longer breaks anything nowadays, but since technically it is > a violation of RFC 2821, it may prove controversial. We are not going to do this unless upstream changes the default. -snip- Would it now be acceptable to change the default in exim of debian as well? Or will we wait till the upstream commit becomes part of a release? Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120509064847.ga22...@kos.to
Re: [proposal] use xz compression for Debian package by default
On Tue, Aug 28, 2012 at 12:10:18PM +0900, Hideki Yamane wrote: > -- > conclusion (rest) > -- > I recommend to use xz ***by default*** (with appropriate option) on not only > i386/amd64 but on ANY architectures. Increasing extract time can be ignore by > decreasing download time and its only part of installation as Mike Hommey > suggested "I/O is still more time consuming than CPU", and nothing worse than > high cpu usage. Thanks for your detailed tests. Wearing armel buildd maintainer hat, I agreei with the conclusion. 1.5x slower decompression is small enough hit and as mentioned decompression is only a part of package install time. It is worth noticing that using xz by default will slow down package builds (especially ones with huge -dbg packages, but we are already working on getting faster armel/armhf build machines. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120828135531.ga6...@afflict.kos.to
