On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> The Debian Hurd project has another category that should be excluded
> because they are kernel-specific. (The current list on the web page
> is update, makedev, ld.so, modconf, modutils, netbase, pcmcia-cs,
> procps, ppp, pppconfig, sets
On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:
> There would definitely be duplication of arch:all between ftp.debian.org
> and ports.debian.org (let's call it ports), as well as duplication of the
> source.
As a mirror operator, I think that this sucks. Badly.
--
ciao,
Marco
signature.a
On Mar 19, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> > > There would definitely be duplication of arch:all between ftp.debian.org
> > > and ports.debian.org (let's call it ports), as well as duplication of the
> > > source.
> > As a mirror operator, I think that this sucks. Badly.
> So don'
On Nov 13, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> I'm sorry, I was under the impression that every package in Debian was
> software. Are you confusing software and computer programs?
No, I just do not believe that this specious distinction is useful.
--
ciao,
Marco
signature.asc
Des
On Nov 13, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Are you saying that Debian has too much documentation? What is the
> non-computer-program which we have "too much" of?
No, I am saying that debian has too many stuff which is not programs nor
their related documentation, like e-zines, bo
On Nov 13, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> > Can you explain exactly how a CC copyleft-like license would have
> > been an obstacle?
> Because it is being incorporated in a larger work: My
So it looks like you have issues with all licenses not compatible with
the one you choo
On Nov 13, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> It seems to me that the papers at a Debian conference are almost all
> related to programs in Debian.
This still does not generally make them documentation.
> Personally, I'd like to read the papers. It's a shame that Debian
> can't dis
On Nov 15, Ian Jackson <[EMAIL PROTECTED]> wrote:
> But, there is another important point: I don't really want a
> debian.org address.
Me neither. In the past the debian-admins suggested that they would
consider allowing to disable them if somebody else implemented
everything needed to do it.
--
On Nov 15, Dave Carrigan <[EMAIL PROTECTED]> wrote:
> No it is not. Just because debian packages don't use 2.95 doesn't mean
> that end users have the same luxury.
Can you point us to some examples of such programs?
Also, are you sure that users will not just be able to install the
2.95 packages f
On Nov 15, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > [I don't want a debian.org address either]. In the past the
> > debian-admins suggested that they would consider allowing to disable
> > them if somebody else implemented everything needed to do it.
> Do we know what would be needed ?
An updat
On Nov 21, Frank Küster <[EMAIL PROTECTED]> wrote:
> What do others think? Would it be acceptable Policy-wise to handle
> configuration like this?
Yes.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Nov 19, Adam Borowski <[EMAIL PROTECTED]> wrote:
> [udev] edit /etc/udev/permissions.rules (owned by the "udev" package,
> and thus out of reach of "fuse-utils" anyway)
Wrong. The correct solution would be to install a new file in
/etc/udev/rules.d/.
--
ciao,
Marco
signature.asc
Descrip
On Dec 05, Joey Hess <[EMAIL PROTECTED]> wrote:
> dh_installmodules generates code to run update-modules in the postinst
> and postrm, which are run when modules are installed or removed. Amoung
> other things, the depmod call in update-modules.modutils makes the newly
> installed modules in the p
On Dec 05, Joey Hess <[EMAIL PROTECTED]> wrote:
> Anyway, if you add a depmod call to update-modules then debhelper could
> just run it and not worry about needing to run depmod. If OTOH you do
> want to eventually remove update-modules from module-init-tools then
> we will have to live with debhe
On Dec 11, Charles Fry <[EMAIL PROTECTED]> wrote:
> But if multiple URLs could satisfactorily serve requests for a single
> repository, only one of them is currently used.
Which is fine, because we do not want people to open multiple
connections to the same server.
--
ciao,
Marco
signature.asc
On Dec 11, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> True, but that's not what's being asked here. If multiple URLs could
> serve requests for a single repository---i.e., if you've got both
> deb http://ftp1.CC.debian.org/debian unstable main
> and
> deb http://ftp2.CC.debian.org/debian unstab
On Dec 12, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Why not open 3 connections one to each host?
Why do?
> Or at least fall back to the other IPs if the first one gives an
> error?
I hope that this already happens...
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 12, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > use more than a single server by itself... I didn't think it common practice
> > for large mirror to configure multi-megabyte windows...
> TCP/IP windows? Or user bw shaping?
He means the TCP window size, and it *is* common pra
On Dec 17, Christian Perrier <[EMAIL PROTECTED]> wrote:
> It is currently very likely that systems with two network interfaces
> will end up with both switched on the installed system after the
> reboot. This is of course a blocker.
>
> The discussion showed that sticking with discover while udev
On Dec 17, Thomas Hood <[EMAIL PROTECTED]> wrote:
> After installation you should have a tmpfs mounted on /run.
I do not remember a consensus about this.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 18, Darren Salt <[EMAIL PROTECTED]> wrote:
> An alternative appears to be to process events in series... or maybe delaying
This was the precedent approach, and it's much slower (also, it cannot
be implemented anymore with just udevd).
--
ciao,
Marco
signature.asc
Description: Digital si
On Dec 18, Graham Wilson <[EMAIL PROTECTED]> wrote:
> > I do not remember a consensus about this.
> Changes in Debian are generally decided by package maintainers, not by
> consensus.
Good to know. So I'm happy that nobody will complain when I will make
udev mandatory.
--
ciao,
Marco
signature
On Dec 18, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I have yet to hear any strong reason why we should _not_ implement
> /run.
> I do not count "It's ugly!" as a strong reason.
It's not needed (since we have /dev/shm/), so it's harmful.
--
ciao,
Marco
signature.asc
Description: Digita
On Dec 18, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > It's not needed (since we have /dev/shm/), so it's harmful.
> Does not follow. Cars aren't needed either (you can always take the
> train, or go by bus), but that doesn't make them harmful.
Cars and trains are different thigs, but a tmpfs i
On Dec 18, Roger Leigh <[EMAIL PROTECTED]> wrote:
> How strongly can I put this? /dev/shm is for *shared memory*, not for
> random junk. /dev/shm is for POSIX shared memory and semaphores
/dev/shm is a tmpfs which happens to be used by POSIX SHM. I have not
seen yet a good reason why it should n
On Dec 18, "Andrew M.A. Cater" <[EMAIL PROTECTED]> wrote:
> Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX
Sure, I often use vim over serial consoles.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 18, Joe Smith <[EMAIL PROTECTED]> wrote:
> 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
> or that if it does exist, that it can be be read as a block device, or that
> if it can, it has a file system on it.
> 2. Neither does FHS.
> 3. The Linux 2.6 device li
On Dec 18, Thomas Hood <[EMAIL PROTECTED]> wrote:
> FWIW I asked Chris Yeoh for his opinion on the name and he said that
> /run sounded preferable to both /etc/run and /lib/run.
Competition with /root in tab-completion, for a start.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 19, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Is there some reason we should be unable to provide a smooth upgrade path
> for users of sarge? Having your network devices scramble themselves on
> reboot is a Big Deal, whether or not it's in the release notes.
This often happens anyway whe
On Dec 18, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > Debian guarantees that it exists on debian systems.
> But what about the future, and what about it being specifically for
> POSIX-SHM?
Tell us... Do you have reasons to believe that we will be forced to
remove /dev/shm/ in the future?
> /run d
On Dec 19, Anthony Towns wrote:
> I note the FHS's limited definition of /lib (essential
> libraries and kernel modules) is already incorrect for /lib/udev,
> /lib/lsb/init-functions, /lib/linux-sound-base, /lib/terminfo, /lib/alsa,
> /lib/alsa-utils, /lib/discover and /lib/init. Especially given
On Dec 19, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> If in the future glibc decides to choose some other implementation
> for shm_open(), then it has no reason to stay.
But it has no reason to go away either, since there are many other uses
too for a tmpfs.
> > > /run doesn't especially /need/ to
On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
> >> If in the future glibc decides to choose some other implementation
> >> for shm_open(), then it has no reason to stay.
> > But it has no reason to go away either, since there are many other uses
> > too for a tmpfs.
> There are many uses for a
On Dec 19, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > Debian guarantees that it exists on debian systems.
> No, we don't. We guarantee it exists on Sarge. It may or may not exist in
> Etch and Sid in the future.
If we use it then it's reasonable to assume that we would not sudden
On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
> With this example, it's trivial to trigger namespace conflicts and
> break shm_open(). "mkdir /dev/shm/foobar", for example, or create a
> symbolic link. These fail outright. If a regular file was opened, it
And so would two programs using the
On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > That tmpfs will not be removed from the kernel just because shm_open()
> > will switch to a different implementation.
> Of course. But if that happened there would be no reason to keep
> /dev/shm mounted; you would need to use an alternate loc
On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote:
> That's correct, but you should still not be using the namespace for
> non-SHM activities.
Because?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 19, Thomas Hood <[EMAIL PROTECTED]> wrote:
> Any other defenders of /lib/run? Of /run?
If it really needs to exist, something of which I am not persuaded, then
at least it should not go in /.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 19, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > > > That tmpfs will not be removed from the kernel just because shm_open()
> > > > will switch to a different implementation.
> > > Of course. But if that happened there would be no reason to keep
> > > /dev/shm mounted; you would need to
On Dec 20, Anthony Towns wrote:
> (TBH, I'd be much happier just making the technical changes necessary
> to ensure /var is mounted early -- keeps the filesystem sane, and it's
> just a simple matter of programming, rather than arguing over what's
Me too.
--
ciao,
Marco
signature.asc
Descript
On Dec 20, Daniel Schepler <[EMAIL PROTECTED]> wrote:
> This is due to changes in make 3.80+3.81.b3-1 concerning how the lines are
> passed to the shell. Previously, they would be concatenated; now they are
> passed verbatim to the shell, backslashes and newlines included (minus the
> first ta
On Dec 27, Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote:
> They fix many bugs wrt debconf by dropping it at all. In addition
> fuse-utils should create /dev/fuse or /dev/.static/dev/fuse device now.
For the benefit of the other debian-devel@ readers: no package other
than udev and makedev s
As you can see, %e will go away soon so /etc/udev/cd-aliases.rules will
not be supported anymore.
Some component of debian will have to install a rules file with static
aliases, and so far I think that this should be a task for d-i.
Comments and other ideas are welcome.
BTW, udevsend will go away
On Dec 29, Frans Pop <[EMAIL PROTECTED]> wrote:
> Is this document still usable for writing udev rules?
> http://www.reactivated.net/writing_udev_rules.html
The basics are there, but since then many new features like support for
environment variables have been added (they are documented in the man
On Dec 29, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Some component of debian will have to install a rules file with static
> > aliases, and so far I think that this should be a task for d-i.
> > Comments and other ideas are welcome.
> What will provide this for systems upgraded from sarge?
Go
To prepare for the eventual removal of makedev, I propose that packages
currently depending on it will add an alternative dependency to udev.
Also, policy should be amended accordingly.
The affected packages are:
alevt
camstream
cdrecord
dvb-utils
fbset
gnupg
gnupg2
irda-utils
isdnutils-base
joys
On Dec 29, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> Huh? rng-tools certainly takes benefit of MAKEDEV. It doesn't bork if
> MAKEDEV has disappeared, though. Is that what you mean?
No. I mean that it currently depends on makedeva while it should depend
on makedev | udev.
> rng-to
On Dec 29, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> Won't work because the problem at hand is exactly that /dev/hdX won't
> necessarily be stable anymore.
No: the /dev/[sh]d* devices are as stable as they have always been.
ONLY rules using %e (the /dev/cdrom-like aliases) are unreliable.
>
On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
> > To prepare for the eventual removal of makedev, I propose that packages
> Er, why is makedev being removed? Please clue me in.
"Eventual" is the key word here.
Because /eventually/ it will not be needed anymore (at least by most
users, which th
On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
> > Because /eventually/ it will not be needed anymore (at least by most
> > users, which then will be able to remove it from their systems).
> Is there something to replace it, completely, in *all* situations?
udev, at least for the general case of
On Dec 30, Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
> bug filed.) Next, it looks like you edit 020_permissions.rules (or
> rather the file it is symlinked to). Maybe you change this line:
>
> ENV{ID_CDROM}=="?*",GROUP="cdrom"
>
> to
>
> ENV{ID_CDROM}=="?*", KERN
On Dec 30, Frank Lichtenheld <[EMAIL PROTECTED]> wrote:
> Hmm, I have a package that depends on makedev (pbbuttonsd) and I was
> wondering why it doesn't show up in your list? Maybe because it
> is powerpc only?
Yes, I did build the list on my x86 box.
--
ciao,
Marco
signature.asc
Description:
On Dec 29, Darren Salt <[EMAIL PROTECTED]> wrote:
> I remember them being reliable. Sacrificing their reliability at the altar of
> boot speed (AIUI) wasn't really a good idea...
No reliability will be sacrified, but some things will have to be
implemented differently.
--
ciao,
Marco
signature
On Dec 31, Joey Hess <[EMAIL PROTECTED]> wrote:
> Is there any good way to map from a given device (or set of related
> devices) in /dev to a udev rule that will match and allow overriding
> only that device?
For the general case, no: e.g. compare udevinfo -a -p /sys/block/hda and
udevinfo -a -p /
On Jan 03, Gene Heskett <[EMAIL PROTECTED]> wrote:
> every legit address I can think of at uol.br.com, with zero bounces,
> so they are either a damned good black hole, or are well aware of the
> nuisance they are being and just don't give a starving rats ass.
[X] they are well aware and do not
On Jan 03, Julien BLACHE <[EMAIL PROTECTED]> wrote:
> I wonder how that's going to happen wrt udev and a couple of other
> things that, as of today, depend on a precise version of the kernel.
udev only depends on a "recent enough" version of the kernel (probably
2.6.15 by the time etch will be fro
On Jan 04, Adam Heath <[EMAIL PROTECTED]> wrote:
> Not to mention that 2.6.15 requires a newer udev. Who knows what other newer
> things newer kernels might require.
OTOH, old kernel are buggy and out of date wrt modern hardware, and we
lack the manpower to backport for years fixes and new featur
On Jan 04, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:
> udev has broken my system -- completely (as in: can't boot and/or log in) --
> _seven_ distinct times since this summer. How on you can claim that ALSA is
> worse, is beyond me :-)
This was not always caused by udev bugs.
And anyway, i
On Jan 04, Nathan Poznick <[EMAIL PROTECTED]> wrote:
> I have a USB card reader which has 5 different slots for various media.
> If I plug in the card reader and then later insert a CF card, the CF
> card slot's device does not have the partition device created when using
> udev (I have to insert
Gated from my blog.
(#104) How the kernel firmware loader works
fEnIo[0] learnt an important lesson about the kernel firmware loader:
it (usually) does not work as expected for non-modular drivers.
The reason is that the request_firmware()[1] interface is synchronous.
Since it's usually called
I uploaded to experimental a udev new package with the (theoretical)
potential of breaking some custom rules referencing sysfs attributes.
I expect that the supporters of experimental will install it today and
report their experience. (Lack of reports will be considered positive.)
--
ciao,
Marco
On Jan 11, martin f krafft <[EMAIL PROTECTED]> wrote:
> How do you think Canonical could *better* work with Debian, ignoring
> whether they meet up to their promises at the moment or not.
E.g. when I repeatedly say "I'd like to receive any change you make to
my packages, in any form you find conve
On Jan 11, Gustavo Franco <[EMAIL PROTECTED]> wrote:
> > E.g. when I repeatedly say "I'd like to receive any change you make to
> > my packages, in any form you find convenient" they could actually do
> > it... I'm tired of begging for patches.
> http://utnubu.alioth.debian.org/scottish/by_maint/[
On Jan 11, Gustavo Franco <[EMAIL PROTECTED]> wrote:
> You said *in any form you find convenient* but which one do you
> prefer: bug reports through Debian BTS, just email, ... ? Please, read
> my reply to Daniel's message.
Uploading the diffs on a web server is nice, but it's not much more
differ
On Jan 12, Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> The relevant context is generally available in the changelog (which is in
At least for my packages, this is often false.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Jan 18, Davide Natalini <[EMAIL PROTECTED]> wrote:
> the system is debian sarge based, with udev version 0.076-6 and kernel
Just to be sure, I suggest you upgrade your version of udev.
> usually the two interfaces are named the wrong way, but sometimes they
> are named fine.
IOW, renaming is
On Jan 18, Emilio Jesús Gallego Arias <[EMAIL PROTECTED]> wrote:
> As far as I can tell, network interface names are given by the kernel
> and they've nothing to do with udev.
Obviously you have no clue about udev (nor about proper quoting).
--
ciao,
Marco
signature.asc
Description: Digital si
On Jan 18, Thomas Hood <[EMAIL PROTECTED]> wrote:
> If you want to avoid racing with the kernel then you should choose
> stable names from another namespace than the one that the kernel uses.
> Suggestion: Use 'eth_0' and 'eth_1' instead of 'eth0' and 'eth1'.
> Md: Or is there something in udevd n
On Jan 19, Davide Natalini <[EMAIL PROTECTED]> wrote:
> maybe modifying mkinitramfs script to include udev in the initramfs
> could help?
udev is already part of the initramfs, but its presence is not relevant.
The options are:
- use names which cannot be used by the kernel, or
- help me cleaning
On Jan 19, Davide Natalini <[EMAIL PROTECTED]> wrote:
> udev now can rename the interfaces, because they haven't a name yet.
udev still loads the modules, you just have been lucky.
This is not a solution in any way.
> furthermore this (or something similar) could be useful if we need some
> modu
On Jan 19, Emilio Jesús Gallego Arias <[EMAIL PROTECTED]> wrote:
> I've looked into the Suse sysconfig package, and it includes all the
> network configuration utils, such as ifup and dhcp handling, and
> they're coupled with the udev rules. As previously said those
Look harder, because there is n
On Jan 19, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> > Interfaces renaming must be handled by udev because if it's not then
> > network hotplug handlers will be called with the wrong interface name.
> When are those network hotplug handlers called?
When udev receives the events from the kernel,
On Jan 19, Davide Natalini <[EMAIL PROTECTED]> wrote:
> maybe I miss something, but for what I see we don't need udev not to
Indeed. udev can rename the modules without any need to mess with the
initramfs or change anything else. Even if the driverss have already
been loaded, network hotplug even
On Jan 19, Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> Is there an objection, or shall I file a serious bug against ffmpeg?
Yes, I object to asking for removal of MPEG encoders because there is no
good reason to do it.
--
ciao,
Marco
signature.asc
Description: Digital signature
Please remove the entry from NEWS.Debian and do not do this again.
Users should not care about who maintains the package.
> xmltv (0.5.42-2) unstable; urgency=low
>
> * After talking with Kenneth J. Pronovici, I have now taken over
> maintainence of this package. I use XMLTV on a regular ba
On Jan 31, martin f krafft <[EMAIL PROTECTED]> wrote:
> Why send this to debian-devel? I suggest talking to Chris directly
Because this way other developers may learn something useful from the
thread.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Feb 03, Daniel Schepler <[EMAIL PROTECTED]> wrote:
> So I'd like to propose moving those data files from netbase to base-files.
> If
No. The correct solution is to fix netbase by moving update-inetd to
each *inetd package.
But aj does not want to do this until update-inetd will have been
rew
On Feb 03, Daniel Schepler <[EMAIL PROTECTED]> wrote:
> If you're suggesting that with a move of update-inetd then netbase would
> become more like the netbase-data I was suggesting as an alternative, with
> minimal dependencies, that would be fine with me.
Yes, because only the files in /etc/ w
On Feb 03, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> That's not quite what he asked. He mentioned "with minimal
> dependencies". Currently netbase provides a basic networking
The dependencies list would be much shortened too.
> I think it's useful to keep this property (and the dependencies
On Feb 03, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> This clause has been examined carefully in the past and deemed ugly
> but not non-free (at least, with no serious objections)--at least in
> the "Apache", etc. cases. However, I don't think that should be extended
> to the general case; "nor m
On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Moreover, while I think a majority of the developers are surely
> honorable, this is not true of everyone. Now that this is the *third*
> time we are being asked to vote on essentially the same question, I
> suspect that many of the prop
On Feb 09, Adam Borowski <[EMAIL PROTECTED]> wrote:
> There are two different definitions of the word software:
> 1. something that can be represented as a finite stream of bits
> 2. a computer program
>
> Definition 1. is precise, definition 2. is not (PostScript, pseudocode,
Unfortunately, def
On Feb 09, Xavier Roche <[EMAIL PROTECTED]> wrote:
> I fully agree. The "Holier than Stallman" stuff is really getting
> ridiculous. After the firmware madeness, now the documentation madeness.
> And after that, the font madeness maybe ? (after all, fonts ARE also
> software, and they shall be dis
On Feb 09, Simon Richter <[EMAIL PROTECTED]> wrote:
> The binutils package generates part of its documentation from header
> files in order to get the structures and constants right. The headers
> are GPLed, the compiled documentation is under the GFDL. For this
> relicensing to happen, one mus
On Feb 09, Thomas Weber <[EMAIL PROTECTED]> wrote:
> > > Definition 1. is precise, definition 2. is not (PostScript, pseudocode,
> > Unfortunately, definition #2 is the one which almost everybody agreed to
> How so? Is there any document in Debian, stating that "software" follows
> definition 2?
On Feb 09, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> This was necessary only because the release manager believed the changes
> to be non-editorial. I cannot even understand an interpretation of the
> old wording that can lead us to accept non-free documentation into main.
This may be annoying
On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Has anyone come forward and said "I was deceived by GR 2004-03"? I
Yes, multiple people did. HTH.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Feb 09, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Or maybe this is only something that has been invented a posteriori when
A search in the debian-devel@ archive of the past years would be enough
to expose this as a lie, but maybe you were not a developer at the time
and so I suppose you cou
On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> > This may be annoying for you, but it's a fact that there is an
> > interpretation of the old wording which has been used for years to
> > accept non-free documentation into main.
> How is this relevant?
It shows that there was a widely
On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> >> Has anyone come forward and said "I was deceived by GR 2004-03"? I
> > Yes, multiple people did. HTH.
> Who? I can't recall any. Can you provide pointers?
Sure, look at the flame which followed aj's message.
> What did they say in
On Feb 10, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Surely it does. People who say "I was deceived; and I didn't bother
> to take elementary steps to avoid deception" have chosen to be
> deceived.
Well, at least now you agree that the GR title was deceiptful.
> Were you "deceived" by the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 13, Klaus Ethgen <[EMAIL PROTECTED]> wrote:
> However it whould be great if update-inetd could create a file in
Many new features in update-inetd would be great, but nobody ever
finished implementing them.
- --
ciao,
Marco
-BEGIN PGP SIGN
On Feb 13, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> I've been wanting to see netkit-inetd gone from base for many many years
> now. Once, aj told me what needed to be done, and I think I even wrote it
> down. Somewhere. I just have to find it again...
This follows the usual pattern: I explain w
On Feb 15, kamaraju kusumanchi <[EMAIL PROTECTED]> wrote:
> This kind of thing is not possible currently. Do you think it is a good
> implement such a feature? Currently bugs.kde.org allows this (searching
> for strings in the bug reports without worrying about package names etc.,).
You use goog
On Feb 17, Robert Millan <[EMAIL PROTECTED]> wrote:
> I see. From http://cipe-win32.sourceforge.net/ :
>
> "CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows NT."
>
> I think this is the cipe-source package in debian. If this driver is already
> available, there's no muc
On Feb 18, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> The same goes for a driver with a firmware.
Drivers do not have a firmware, hardware devices do.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Feb 19, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> I wonder why all people go on trying to build up tons of different
> fallacious reasonings to keep firmwares in main.
Because it's good for Debian and is good for our users.
> Non-free is here for a
> reason, we just have to use it. Technic
On Feb 19, Robert Millan <[EMAIL PROTECTED]> wrote:
> Nevertheless, if you think abiword and openoffice.org should be moved then go
> for it. Just don't use them as excuse to turn warez wrappers into "generic"
> driver interfaces.
No excuses are needed, the definition of contrib is enough and
ndi
On Feb 19, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Indeed. It has with the fact there is no reasonable use of ndiswrapper
> that doesn't imply installing (and running) non-free software on the
> host machine. The key here is "reasonable". This is a practical case,
> not something to build up
On Feb 20, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> Come on. The farce is that, two years later, people are _still_
> complaining because they didn't read the thing they voted on, or that
> they didn't bother to vote at all. Can you all please stop?
No, it will never end. A few people manage
101 - 200 of 1926 matches
Mail list logo
