Re: If *-module depends on *-utils, should *-source recommend it?
Once upon a time Scott James Remnant said... > On Tue, 2005-01-11 at 11:15 +1100, Cameron Hutchison wrote: > > > dpkg first removes foo-modules_1.0 > > dpkg then check dependencies of foo-modules_2.0 > > dpkg complains that foo-utils is not installed and aborts the > > installation of foo-modules_2.0 > > > This is incorrect. > > dpkg doesn't remove foo-modules_1.0 at all. Ok. If we change the above sequence to: dpkg unpacks the data contents (data.tar.gz) of foo-modules_2.0 into their final location in the filesystem (possibly overwriting the contents of the package being replaced) dpkg then checks dependencies of foo-modules_2.0 dpkg complains that foo-utils is not installed and aborts the installation of foo-modules_2.0 Is this correct? I gather it is from what you have elaborated further on in the thread. Would it not make sense to change the order of the first two items in the list? I think the reversed order is correct and the current order is not - but that's based only on my limited understanding. Is there a reason that the data.tar.gz needs to be unpacked before the dependencies are checked to see if the package can be installed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Mon, Jan 10, 2005 at 11:07:52PM -0800, Steve Langasek wrote: > in ways that were not backwards-compatible: automatically pulling in the > -utils could render the system networkless before you've even started to > *build* the modules... In theory, yes if ndiswrapper-modules has a versioned dependency on ndiswrapper-utils, but (1) it doesn't so no and in the worst case (2) if it did it would be immediately fixable by immediately building and installing the modules. You'd be networkless but it would be fixable, instead of networkless and not fixable. This is actually not too different from the problems people get into in the COM world where they make breaking changes to CLSIDs and IIDs. The solution is the new IID has to be backwards compatible (no versioned dependency) or else you need side by side execution (both versions of ndiswrapper-utils installed simultaneously). Is it anathema for a modules package to just install utils as well? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Mon, Jan 10, 2005 at 09:51:54PM -0600, Matthew Dempsky wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > On Mon, Jan 10, 2005 at 05:17:19PM -0600, Matthew Dempsky wrote: > >> It seems like the common case for wanting to install a kernel module > >> source package is to build the module and then install it on the same > >> box. Since the *-source package doesn't really depend on *-utils, why > >> not add a Recommends line? > >> For example, ndiswrapper-source would Recommend ndiswrapper-util, > >> while ndiswrapper-module-* would Depend on ndiswrapper-util still. > >> (Similarly for alsa-*, and any other modules.) > > The build system may not be the same as the system where the package will be > > installed, or one may be a chroot of the other, in which case this is > > needless overhead. > Hence the Recommends instead of Depends. Recommends means "packages that would be found together with this one in all but unusual installations". It is not unusual to have a single designated build machine in an organization, which may or may not ever have the final binary packages installed. > > There is nothing in the -source package that actually requires (or should > > recommend) the -utils package. > Sure, nothing requires the -utils package, but does the fact that the > package it generates depends on -utils not mean the -source package > should recommend it? Why? Installing the -utils package does not make the -source package more or less useful. It only makes the -modules package more useful; until you install the -modules package there isn't actually any use for the -utils package at all. > > A much better fix here is for people to get over the fact that dpkg > > isn't apt. > Am I confusing them some how? Not that I can tell, but the root reason people are asking for this functionality is that they want -utils packages to be installed for them automatically when they use -modules packages; when getting the support packages installed is actually quite trivial with even the slightest bit of advanced planning and/or reading of error messages. The real irony is that, with the package in question, automatically pulling in -utils with -source could cause *more* users' systems to break, because the interface between ndiswrapper-utils and ndiswrapper-modules has changed several times recently in ways that were not backwards-compatible: automatically pulling in the -utils could render the system networkless before you've even started to *build* the modules... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, Jan 11, 2005 at 06:53:57AM +, Scott James Remnant wrote: > On Tue, 2005-01-11 at 01:35 -0500, William Ballard wrote: > > > On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote: > > > dpkg doesn't remove foo-modules_1.0 at all. > > > Note that I said "remove", the old files are replaced during the unpack > phase rather than removed. In what sense is banana/foo 1.0 "not removed" ? As to the rest of your post -- reread this thread more carefully. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, 2005-01-11 at 01:35 -0500, William Ballard wrote: > On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote: > > dpkg doesn't remove foo-modules_1.0 at all. > Note that I said "remove", the old files are replaced during the unpack phase rather than removed. It's generally assumed that if you're unpacking a package, you actually want it installed. 1) No banana or icecream: descent tmp# dpkg -s banana Package: banana Status: purge ok not-installed Architecture: all descent tmp# dpkg -s icecream Package: icecream Status: purge ok not-installed Architecture: all 2) Install banana 1.0: descent tmp# dpkg -i banana_1.0.all.deb Selecting previously deselected package banana. (Reading database ... 140490 files and directories currently installed.) Unpacking banana (from banana_1.0.all.deb) ... Setting up banana (1.0) ... descent tmp# cat /banana This is banana 1.0. descent tmp# dpkg -s banana Package: banana Status: install ok installed Maintainer: Scott James Remnant <[EMAIL PROTECTED]> Architecture: all Version: 1.0 Description: yellow fruit 3) Upgrade to banana 2.0 (which needs icecream): descent tmp# dpkg -i banana_2.0.all.deb (Reading database ... 140492 files and directories currently installed.) Preparing to replace banana 1.0 (using banana_2.0.all.deb) ... Unpacking replacement banana ... dpkg: dependency problems prevent configuration of banana: banana depends on icecream; however: Package icecream is not installed. dpkg: error processing banana (--install): dependency problems - leaving unconfigured Errors were encountered while processing: banana As you point out, banana 2.0 has been unpacked: descent tmp# cat /banana This is banana 2.0. And is left in an "unpacked" state, rather than installed: descent tmp# dpkg -s banana Package: banana Status: install ok unpacked Maintainer: Scott James Remnant <[EMAIL PROTECTED]> Architecture: all Version: 2.0 Config-Version: 1.0 Depends: icecream Description: yellow fruit 4) We need icecream, so install it: descent tmp# dpkg -i icecream_1.0.all.deb Selecting previously deselected package icecream. (Reading database ... 140491 files and directories currently installed.) Unpacking icecream (from icecream_1.0.all.deb) ... Setting up icecream (1.0) ... 5) And complete configuration of banana: descent tmp# dpkg --configure -a Setting up banana (2.0) ... descent tmp# dpkg -s banana Package: banana Status: install ok installed Maintainer: Scott James Remnant <[EMAIL PROTECTED]> Architecture: all Version: 2.0 Depends: icecream Description: yellow fruit Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: hwcap supporting architectures?
At Sat, 25 Dec 2004 21:59:41 -0600, Marcelo E. Magallon <[EMAIL PROTECTED]> wrote: > Since the optimized i386 library does use MMX (it does perform runtime > checking) and is compiled with -mcpu=i686 [0] (gcc doesn't seem to be > emitting CMOVs though) I think the proper place is > /usr/lib/i686/mmx/cmov (I have no intention of babysitting the > generation of cmovs with each difference compiler release, therefore > mmx/cmov instead of just mmx) If it uses i686 and mmx code, /usr/lib/i686/mmx/cmov is OK. Note that MMX will be removed from the next glibc 2.3.4 upload. It will provide only SSE2 (and CMOV, debian-specific for only VIA C3 processor). If you want to keep adding mmx, we may need discussion about this issue in future. But nowadays many processors can use SSE2, so I guess changing cmov to SSE2 can fix the problem. > My understanding is that this is also significant on sparc (-mcpu=v9) > and that this belongs in /usr/lib/v9. Is this right? Sparc defines HWCAP_SPARC_V9 and HWCAP_SPARC_ULTRA3. So v9 is right. See glibc sparc packages. > Mesa upstream uses -mcpu=ev5 -mieee on alpha. Is that ok? Where does > this belong into? /usr/lib/ev5? IIRC, alpha does not define any hwcaps. > It also uses -mcpu=603 on powerpc. From my understanding this is a lot > hairier than other architectures since there's a whole load more > subarchitectures which are potentially incompatible with each other. Powerpc does not define any hwcaps, too. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
So I'm confused, because each mail seems to contain a plethora of options, but when I picked through the last one and found what seemed to be right, you say it's wrong. So I just did two uploads already, based on the previous mail, which I have apparently misunderstood. Please reject those (as I'm sure you will anyway). Anthony Towns writes: > You're really better off just getting libofx 0.7.0 uploaded > correctly, and everything that depends on the old lib fixed and/or > NMUed though. Well, my concern is that this will hose grisbi. The new library contains new initialization functions and changes the interface for doing callbacks. Maybe it hoses grisbi, and maybe it doesn't. I am not in a position to detect hosage if it is happening. And, worse yet, grisbi is written entirely in French and I can't even read the documentation, and I don't even have access to OFX banking (ask my credit union when they'll decide to start supporting it). But since this is what you prefer I'll happily do this (as quoted above), and file a RC bug against grisbi to have it recompiled against the new library. It's easier for me to maintain anyway. If that hoses grisbi in such a way that the grisbi maintainer can't deal with the result, then we'll have to deal with the fallout then. Thank you for your patience. I'm uploading now the following .dsc which should be correct. Thomas -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 10 Jan 2005 22:28:16 -0800 Source: libofx Binary: libofx1 libofx-dev Architecture: source powerpc Version: 1:0.7.0-6 Distribution: unstable Urgency: low Maintainer: Thomas Bushnell, BSG <[EMAIL PROTECTED]> Changed-By: Thomas Bushnell, BSG <[EMAIL PROTECTED]> Description: libofx-dev - development package for libofx1 libofx1- library to support Open Financial Exchange Changes: libofx (1:0.7.0-6) unstable; urgency=low . * I misunderstood the instructions of the ftp masters. Revert the name of the -dev package to libofx-dev (without number). Files: 292b5ebc532f79d88410061bbf8d9c62 614 libs optional libofx_0.7.0-6.dsc 433113876dcfd213127c76a89fb557db 63089 libs optional libofx_0.7.0-6.diff.gz 29c5bb6c5da8d12491ced7fa20d581a2 542960 libs optional libofx1_0.7.0-6_powerpc.d eb 3da9438e6b5cd7ee9680a7dcb1d00f88 335746 libdevel optional libofx-dev_0.7.0-6_po werpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB43O+qMsB9b6fcOoRAsBcAJ4weGOx+XQs2faevWbRmpSIbBl2aQCgolZ5 SDcs9mdiojwQ+h7UOpAnGQg= =8/nn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote: > dpkg doesn't remove foo-modules_1.0 at all. I used equivs to make a package "foo", version 1.0, and installed it. I used equivs to make a package "foo", version 2.0, which depend on "bar", which doesn't exist. Tried to install it with dpkg -i. It failed. /var/lib/dpkg/status contains: Package: foo Version: 2.0 Config-Version: 1.0 Depends: bar /usr/share/doc/foo/changelog.gz contains: foo (2.0) unstable; urgency=low It looks to me like the files for "foo version 1.0" have been clobbered, at least in /usr/share/doc/foo/ Where are the unpacked files for foo 2.0 kept where they are not clobbering the foo 1.0 files? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug #267273: cdrecord and 2.6.x bug possibly fixed
I just upgraded to cdrecord version 2.01+01a01-2.[1] I found that with permissions -rwsr-xr-- on /usr/bin/cdrecord [2] that I was able to record a CD without having to become root first using dev=/dev/hdc and kernel 2.6.10 [3]. Do any others still have problems burning CD's as non-root with kernels >= 2.6.8 or shall I close the bug? [1] Straight from the archive. I did not applying redhat's patch in debian bug #267273, and it does not appear to have been applied by the maintainer. [2] I don't recall whether these permissions are default for cdrecord, so I'm mentioning them here to make sure [3] Compiled from the vanilla kernel.org sources. -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. signature.asc Description: Digital signature
Re: System snapshots
On Mon, 2005-01-10 at 18:40 +0100, Petter Reinholdtsen wrote: > [Otavio Salvador] > > No because some applications doesn't depends only of configuration > > files but data-files. When you purge then, all data files will be > > removed together (in major of times). Another problem is how you can > > revert upgrade processes in database files and like? > > RPM have a feature allowing it to do upgrade transactions and rollback > of failed installs, where it will include the data files in the > transaction log. I read about this in the Linux Journal article > "Transactions and Rollback with RPM" by James Oden, > http://www.linuxjournal.com/article/7034>. > > Such feature would be nice to have in Debian as well. If you have a > very short upgrade window, where one will have to abort and roll back > if the upgrade fail, it would be helpful if dpkg would allow you to > roll back the upgrade. > Feel free to spec something out on http://www.dpkg.org/ Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: rudeness in general
On Mon, 2005-01-10 at 20:38 +0100, Miros/law Baran wrote: > 10.01.2005 pisze Ron Johnson ([EMAIL PROTECTED]): > > > > 'RTFM' means "Go read the documentation, that's what it's for". I > > > personally find it far more rude to go on a mailing list, ask for the > > > Do you *really* think that RTFM means "Go read the documentation, > > that's what it's for"? > > If one has the skin not thick enough to read the proper meaning from > RTFM, one should not use mailing lists and should concentrate on dead > tree repositories. Being oversensitive in public is usually > counterproductive. > I was looking for a spot to post this link because I've been there before, and this reply is as apropos as it gets. As long as new people are allowed to use operating systems that have man pages this issue will come up. It's not that we didn't/don't have thick skins, it's because _we did not yet know_ that there are two ways to read the F: one obvious, one learned; one dismissive, one informative - and, unless the context is obvious, that 'fine' is assumed :) So, and back to the subject at hand, there are also two ways to share information: Craig's, and yours. Guess which is worth the storage bits, and remember: one day your kids will search for your mail on the net. (Sorry about the long link, but it summarizes my point best) http://groups-beta.google.com/group/linux.debian.devel/browse_frm/thread/49ad0896f43894e4/2a1406cefa976f8a?q=ingram+debian+kpkg&_done=%2Fgroups%3Fq%3Dingram+debian+kpkg%26qt_s%3DSearch+Groups%26&_doneTitle=Back+to+Search&&d#2a1406cefa976f8a Here's the whole thread, for completeness. http://lists.debian.org/debian-devel/2001/09/msg01593.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
On Tue, 2005-01-11 at 05:05 +1100, Sam Watkins wrote: > Even if the d-d for ndiswrapper has done something wrong or not, even if > the upstream package is better (I don't know the facts, and I'm not > personally interested), it is NOT necessary to be rude and go on the > offensive like this. Please simply state your case, using calm language > and unadorned facts (as you see them) and let people discuss the > technical issues without all the "You've F'd it up beyond all > recognition", "horribly broken" etc. Believe it or not, some people get > upset at this sort of stuff, even when it's not directed at them. > > Several people - not just me - have complained about unnecessary > flamage, rudeness, bad language, personal abuse, etc. on the Debian > lists and the IRC channel in recent months. Let's cut it out and > remember that we're talking in public, on an archived list, we're > supposed to be representing Debian here. This kind of talk does not > give Debian a good name. > To heck with representing debian, we each represent ourselves, and we are out there _FOREVER_. There's some 20 year old stuff I would love to obliterate. (It still can be found if you're good, but I'm not telling :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RunDinstallHourly
Matt Zimmerman wrote: On Mon, Jan 10, 2005 at 10:54:34PM +, Steve McIntyre wrote: FWIW, our experiences with Ubuntu shows that having fast dinstall cycles is very helpful. [...] It's a variant of the ïrelease often, release earlyï principle. (Strictly, it's an instance of the principle) The downside of doing this [...] It might affect the mirrors, too... It would only affect the mirrors if they polled (or were pushed) more frequently; that frequency could remain the same even though packages were installed more frequently. That wouldn't do any good though -- the point of this thread is getting quicker feedback from users, which doesn't happen if the only site that gets the updated packages quicker doesn't let anyone download from it. The other benefits of installing packages more quickly -- working out if you've screwed up the upload, or that they don't build -- already happen in response to the package getting accepted anyway. So you have to sync the mirrors more often for it to be useful... Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, 2005-01-11 at 11:15 +1100, Cameron Hutchison wrote: > dpkg first removes foo-modules_1.0 > dpkg then check dependencies of foo-modules_2.0 > dpkg complains that foo-utils is not installed and aborts the > installation of foo-modules_2.0 > This is incorrect. dpkg doesn't remove foo-modules_1.0 at all. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: ok, i screwed up
Thomas Bushnell BSG wrote: Anthony Towns writes: PLEASE DON'T INTRODUCE NEW PACKAGE NAMES GRATUITOUSLY. So it seemed to me that because of my previous mistake it wasn't gratuitous. See the previous message for non-gratuitous reasons to change package names. That wasn't one of them. Bumping the actual revision of the libfoo-dev package (and having libfoo2-dev) is only useful if the source API of the library changes significantly. Yes, this was necessary in this case. The source API, according to upstream, has significantly changed in the new 0.7.0 release of libofx. The way to tell if a package "significantly" changed it's API, is if most packages don't rebuild without significant source changes. From the other messages in the thread, that seems to be not the case. I can't see any reason to bother with keeping the old version around -- users can just keep the old libofx0c102 (?) package if they've got packages that depend on it. (a) The last upload of libofx was buggy. Oh well, bugs happen, let's move on. Upload libofx.dsc with libofx1.deb (and ideally lintian errors fixed) Make sure any package that linked against the buggy libofx upload is fixed ASAP. Make sure any packages that link with libofx get updated to the new ABI RSN too. There should be no links against the buggy libofx. So this is the step. Yes. (b) The old libofx needs to be supported. Upload libofx0.dsc with libofx0c102.deb and libofx0-dev Do (a), with less of a rush on "RSN". Yes, this is still necessary. No, it's not. First, as I mentioned in the reject messages there's never any reason to introduce a new package into oldlibs. It doesn't help users of other packages that get removed, since it won't satisfy their dependencies anyway; and if we could live without that package name before, we can live without it now. But second, since there are so few packages that use it, it's not worth delaying the transition; just rebuild the packages that use it and be done with it. Note that (again as I mentioned in the reject messages) you should avoid having bins and dtds and other unversioned files in libpackages. This is so that users can have both the old libofx0c102 and libofx1 installed simultaneously, without conflicts, if they need to without you having to maintain packages in oldlibs. source package libofx, binary packages libofx1 and libofx1-dev (in libs) source package libofx0, binary packages libofx0c102 and libofx0-dev (in oldlibs) The main libofx package should provide the current library. The -dev package name shouldn't change unnecessarily. A compat package should be in oldlibs only if necessary. So, the ideal is to replace "libofx builds libofx0c102, libofx-dev" with: libofx builds libofx1, libofx-dev This is all libofx actually needs, afaics. Note that libflac has just been in exactly the same situation, and this was how it was resolved. The simplest level of compatability (if it's going to take ages to rebuild all the packages, but they're relatively easy to rebuild, or if important non-debian/non-free apps require the old version) libofx builds libofx1, libofx-dev libofx0 builds libofx0c102 (ie, take the old version, and make it only build the lib, not the -dev package and rename the source package) If people need to be able to build packages against the old libary as well (if it's part of the LSB spec is the only reason I can think of), you'll want: libofx builds libofx1, libofx-dev libofx0 builds libofx0c102, libofx0-dev (ie, take the old version, rename its -dev package, and the source package) Note that in all the cases, we can just drop libofx0.dsc and forget libofx0 ever existed. If there's a major API change, and packages are continuing to be developed against the old library because, say, the new version has dropped some features as part of a major rewrite that haven't yet been readded, you'll want: libofx1 build libofx1, libofx1-dev libofx builds libofx0c102, libofx-dev Note that in this case, libofx stays the same, and it's a matter of uploading a new libofx1 source package, that builds .debs under new names. Why? Because you've effectively got a completely new library, old binaries won't work with it, old sources won't build against it, and it doesn't even obsolete the old one. This way of doing things means you don't break any old dependencies, and have complete control over what dependencies (normal or Build-) the new packages satisfy. It also means you only have to wait for one package to be processed through NEW. You don't normally need this case at all. For values of "normally" approaching "ever". There's no particular need to fix libofx0c102 in unstable before completely replacing it with libofx1 -- things break in unstable, it happens. The fix for unstable users is just rebuilding everything to work with libofx1; if they really care they can get the old working libofx0c102 f
Re: ok, i screwed up
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> > Anyway, Thomas, I've rejected your pending uploads, please start
> > again.
>
> Alas, I can't, because the mistaken upload of 0.7.0 under the name of
> libofx still happened, and is still in the archive causing problems.
This comment ("I can't") is confusing and I shouldn't have said it
that way. I didn't mean I can't fix it (the rest of my mail is my
understanding of what you want me to do); I just meant I can't start
again, because the mistaken upload has broken things. But it hasn't
broken anything that isn't fixed with an epoch, so that's done.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
Anthony Towns writes: > PLEASE DON'T INTRODUCE NEW PACKAGE NAMES GRATUITOUSLY. So it seemed to me that because of my previous mistake it wasn't gratuitous. Regardless, I'm happy to do whatever you think best, provided it solves the problem. I certainly do agree that it is a thing to be avoided; if my judgment was off kilter in this case, thanks for correcting it. I know the normal procedure, which is your (a), but in this case because of the ABI change and the need to keep the old library working for the sake of the other package, (b) would have been the right thing. But it's too late for that now, alas. > Bumping the actual revision of the libfoo-dev package (and having > libfoo2-dev) is only useful if the source API of the library changes > significantly. Yes, this was necessary in this case. The source API, according to upstream, has significantly changed in the new 0.7.0 release of libofx. > Anyway, Thomas, I've rejected your pending uploads, please start > again. Alas, I can't, because the mistaken upload of 0.7.0 under the name of libofx still happened, and is still in the archive causing problems. > (a) The last upload of libofx was buggy. Oh well, bugs happen, let's > move on. > > Upload libofx.dsc with libofx1.deb (and ideally lintian errors > fixed) > > Make sure any package that linked against the buggy libofx upload is > fixed ASAP. Make sure any packages that link with libofx get updated > to the new ABI RSN too. There should be no links against the buggy libofx. So this is the step. > (b) The old libofx needs to be supported. > Upload libofx0.dsc with libofx0c102.deb and libofx0-dev > > Do (a), with less of a rush on "RSN". Yes, this is still necessary. So I want to be crystal clear, just so that I don't make a mistake. I'll wait until I get confirmation from you. But I'm a little confused. I always just use dpkg-buildpackage, which seems like the right way to proceed. You want: source package libofx, binary packages libofx1 and libofx1-dev (in libs) source package libofx0, binary packages libofx0c102 and libofx0-dev (in oldlibs) Have I got that correct? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
Thomas Bushnell BSG wrote: Santiago Vila <[EMAIL PROTECTED]> writes: I've created libofx0 and libofx1 which are the old and new versions, and ask the ftp-masters to drop the old package entirely. I'll request the other user of libofx to adapt accordingly. Gar. PLEASE DON'T INTRODUCE NEW PACKAGE NAMES GRATUITOUSLY. Did everyone hear that? You guys at the back? Seriously, don't do it. It's stupid. The *only* good reason to introduce a new package name is if you've got a new package. The *only* thing it does is delay development because the new packages have to be manually reviewed, and cause breakages on user's machines. Both of those are *bad*, mmm'kay? If you're bumping a library soname, you should do precisely one of precisely two things: (a) Bump the revision of the library package (eg libfoo1.deb -> libfoo2.deb, libfoo.deb -> libfoo5.deb, whatever) Optionally bump the revision of the -dev package's Provides (eg libfoo-dev Provides: libfoo1-dev -> libfoo-dev Provides: libfoo2-dev) Upload libfoo.dsc, wait for libfoo2.deb to be approved as NEW. Make sure everyone who uses your package upgrades to the new ABI. This means getting a list of those packages, making sure the maintainers of those packages know what's happening. Filing serious bugs when the old libfoo1.deb package is removed from the archive, and possibly NMUing those packages. _or_ (b) Create a copy of the existing package "libfoo.dsc" called "libfoo1.dsc". Rename "libfoo-dev" to "libfoo1-dev". Move them to Section: oldlibs. Update "libfoo.dsc" to the new version as per (a). Remove any packages still in libfoo.dsc from libfoo1.dsc; ie anything that doesn't get versioned (like foo-utils), or anything that's versioned but didn't need a version bump (like libbar3). Upload libfoo1.dsc, libfoo.dsc. Make sure everyone who uses your package knows there's a new ABI to be upgraded to. File wishlist bugs to ensure they know what's going on. File patches to those bugs. NMU them to ensure none of them continue to depend on oldlibs libraries. The primary reason to do (b) is if third party apps often use the old library. The secondary reason is if there are a lot of packages depending on your library in Debian and you want to have a little time to do the transition. Bumping the actual revision of the libfoo-dev package (and having libfoo2-dev) is only useful if the source API of the library changes significantly. Anyway, Thomas, I've rejected your pending uploads, please start again. I'd suggest either: (a) The last upload of libofx was buggy. Oh well, bugs happen, let's move on. Upload libofx.dsc with libofx1.deb (and ideally lintian errors fixed) Make sure any package that linked against the buggy libofx upload is fixed ASAP. Make sure any packages that link with libofx get updated to the new ABI RSN too. (b) The old libofx needs to be supported. Upload libofx0.dsc with libofx0c102.deb and libofx0-dev Do (a), with less of a rush on "RSN". For the libflac problems we just had, we chose (a) because there weren't any packages linked against the buggy libflac4, and getting packages updated to libflac6 is expected to be easy. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Steve Langasek <[EMAIL PROTECTED]> writes: > On Mon, Jan 10, 2005 at 05:17:19PM -0600, Matthew Dempsky wrote: >> It seems like the common case for wanting to install a kernel module >> source package is to build the module and then install it on the same >> box. Since the *-source package doesn't really depend on *-utils, why >> not add a Recommends line? > >> For example, ndiswrapper-source would Recommend ndiswrapper-util, >> while ndiswrapper-module-* would Depend on ndiswrapper-util still. >> (Similarly for alsa-*, and any other modules.) > > The build system may not be the same as the system where the package will be > installed, or one may be a chroot of the other, in which case this is > needless overhead. Hence the Recommends instead of Depends. > There is nothing in the -source package that actually requires (or should > recommend) the -utils package. Sure, nothing requires the -utils package, but does the fact that the package it generates depends on -utils not mean the -source package should recommend it? > A much better fix here is for people to get over the fact that dpkg > isn't apt. Am I confusing them some how? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
Charles Plessy wrote: On Mon, Jan 10, 2005 at 07:14:29PM +0100, Wouter Verhelst wrote : Why don't guys go to psychology class before telling people not to be 'rude'? Then what about keeping jokes for our private messages to our friends ? Your suggestion to go back to classes is, to my standards, definetly rude. One of the tenets of internet communications is "be conservative in what emit, and liberal in what you accept". It roughly translates to "be both inoffensive, and hard to offend". You're failing at the latter. 'RTFM' means "Go read the documentation, that's what it's for". It also contains the "F word", which is related to the act of having sex. Weird, I don't immediately associate "Fine" with sex. You must have a dirty mind... Anyway, this is surely off topic for -devel. Can we go back to talking about hot babes or something? Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
Wouter Verhelst wrote: lemma A: If people disagree, that's their problem. lemma B: In any case, I strongly disagree with the stance that the rudeness of a particular developer would reflect on Debian as a whole. lemma C: That's your problem proof from B have "You disagree" by simp with A show ?thesis by simp In particular, if you're not willing to help other people with their problem (that they think "RTFM" is rude, eg), then you should expect anyone else to help you with your problem (that people experience rudeness from one developer, and conclude Debian's rude in general). We're meant to be working together to create an operating system, dismissing complaints with "that's your problem" doesn't help with that. If you don't want to help solve a problem, that's fine: just don't. But "Well, that's your problems." goes further, potentially to the point of stopping the problem from being solved at all. (OTOH, there are other ways of resolving "RTFM is rude!" than never saying "RTFM" again.) Cheers, a "theorem D: Isabelle is cool" j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MPEG in general Was: Is anyone packaging `lame' ?
On Mon, Jan 10, 2005 at 11:55:30PM +0100, Tollef Fog Heen wrote: > * Chris Cheney > > | Its all encumbered, there is a separate organization MPEG-LA that > | strictly deals with the licensing. It is quite surprising to me that > | ffmpeg was allowed into main. > > According to rumors I heard, it was allowed in since other > applications (xine at least, I think) already included it. So it > didn't really make a difference -- if we're infringing on patents with > ffmpeg, we are with xine as well. > > (Apologies if xine is not the package I'm thinking about.) Wouldn't that be an argument to have xine removed from Debian not the addition of ffmpeg? Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
On Tue, Jan 11, 2005 at 01:21:10PM +1100, Sam Watkins wrote: > Public ing, unless in response to extreme provocation, is also > very rude. If you want to killfile someone, go ahead. Send them a > private message, but don't make a scene of it. I disagree. There are times when I find it appropriate to announce to the rest of a discussion that I find somebody's behavior that bad; for example, to hint a third party (such as an upstream author) that one person's behavior or impatience isn't shared universally. I also find it appropriate to announce when I'm dropping out of a "debate" after my abuse tolerance is exceeded. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: remove me
On Mon, 10 Jan 2005 23:07:06 +0100, Christian Perrier
<[EMAIL PROTECTED]> wrote:
> Quoting Michelle Konzack ([EMAIL PROTECTED]):
> > rm -rf [EMAIL PROTECTED] >/dev/null
> Nope, you're definitely wrong. The correct command line should be:
>
> cd "call wave" ; rm -f [EMAIL PROTECTED] >/dev/null
>
> The user explicitely asked for being removed from call wave only.:)
>
> I'm pretty sure other fellow DD's will find nice ways to enhance this
> and correct my poor shell syntax, though.
=)
Removal from all instances would be required:
updatedb
locate "call wave" | grep "[EMAIL PROTECTED]" >> possible_call_wave_locations
perl -w removal.pl possible_call_wave_locations
= cut source ===
use strict;
use diagnostics;
# must be root...
die "You are not root ... good-bye..." if $<;
# Pass me a file to parse - unless I am NOT root...
my $remove = @ARGV ? $ARGV[0] : 'unknown';
# Exit on error...
die "nothing to parse ..." if ($remove =~ /unknown/i);
# You *could* sort the data ... something like
# my $sorted = `cut -f3 -d: $gf > $us && sort -n $us`;
my $erc= '';
my $test = '';
my $targets = 0;
foreach $test ( (split(/\n/, $removal)) ) {
$erc = system("rm -fR $test") / 256 unless $<;
print "\n\nError Cannot remove you from Call Wave $! $erc" if $erc;
}
__END__
*** modified from:
http://backpan.cpan.org/authors/id/S/SN/SNEEX/addgroup.sx
This is all totally in good fun and completely untested...
Cheers!
--
WC -Sx- Jones
http://insecurity.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
Wouter Verhelst <[EMAIL PROTECTED]> writes: > It's impossible not to be rude on written media. What's a harmless joke > to one is an insult to another, and an attack to one's personality to a > third one. You can't expect everyone to be happy with everything you > might possibly write. Of course not, but it's certainly possible to a lot better... I suppose some rudeness on this list is inadvertant, but I think in most such cases people realize full well that their manner of expression is annoying/offensive to many readers; being snarky seems to be sort of "part of the game." -Miles -- We live, as we dream -- alone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
I accidentally posted the following to debian-user this morning, it was supposed to go to debian-devel in this thread; please excuse me re-posting it. On Mon, Jan 10, 2005 at 07:14:29PM +0100, Wouter Verhelst wrote: > It's impossible not to be rude on written media. What's a harmless > joke to one is an insult to another, and an attack to one's > personality to a third one. Sure, misunderstandings happen. But people are also objectively rude, whether deliberately or as a matter of careless habit - this is what I find unacceptable, not the occasional misinterpreted joke or whatever. Deliberate or careless rudeness is much more common on our lists that such misunderstandings. If I say "Debian might release sarge any *year* now :)", that is not objectively rude (although it might be a mild troll depending on my intent). If someone responds by calling me a "[EMAIL PROTECTED] loser" or tells me to go to hell, that is unacceptably rude. That is an unacceptable response on a Debian list, no matter what the provocation. Public ing, unless in response to extreme provocation, is also very rude. If you want to killfile someone, go ahead. Send them a private message, but don't make a scene of it. > You can't expect everyone to be happy with everything you might > possibly write. Similarly I can't expect that I will always write code that is completely free of bugs - nevertheless I try not to write buggy code, and I try not to offend people unnecessarily. You seem to be saying that we shouldn't attempt to address the issue of rudeness because we can't achieve perfect harmony and concordance. > 'RTFM' means "Go read the documentation, that's what it's for". I > personally find it far more rude to go on a mailing list, ask for the > obvious, and expect a bunch of volunteers to come up with an answer > that's been answered in great detail in the documentation, than to be > sent back with an 'RTFM' as answer to that question. I suppose there might be two kinds of "RTFM" response to a newbie question, about bash completion for example: 1. Go read the bash manual. (and stop wasting our precious bandwidth and time!) 2. Try "info bash", type ^S for interactive search, then "completion". Check out the info tutorial, if you haven't used it before :) The first response is unacceptably rude, a _real_ waste of bandwidth. Even "Go read the bash manual." by itself is no good. The second response is fine, because it is polite and helpful. If the newbie keeps asking questions before checking the manual, you can answer his question politely and then suggest - politely - that next time he ought to check the manual before posting. If you've got time to reply, you've got time to do a good job. If not, leave replying to some volunteer who _doesn't_ find it rude when people ask the obvious. > In any case, I strongly disagree with the stance that the rudeness of a > particular developer would reflect on Debian as a whole. When people are excessively and unjustifiably rude and others just let it pass, it does reflect badly on Debian. When people use obscene or abusive language, and everyone lets it pass, this passive approval reflects badly on Debian. It even drives people away from Debian. If we get accustomed to accepting rudeness and talking aggressively among ourselves, we will start treating outsiders similarly. I am particularly upset that several people on debian-legal were rude to RMS during the discussions about the GFDL. Many people find obscenity and aggression offensive. This is one of the reasons why some women have left the male-dominated groups and started separate lists and groups. Men are often welcome to join such groups too (e.g. linuxchix) - provided they behave civilly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
Steve Langasek <[EMAIL PROTECTED]> writes: > How is this possible? By my count, this leaves us with one package using > each API. Wouldn't it be easier to port one of these packages to the new > API, instead of bloating oldlibs for such a niche library? How different of > an API are we talking about, after all? I conducted an experiment, and grisbi does compile against the new libofx without errors. But I cannot test it, and I'm not the grisbi maintainer. So if it's important to have the old libofx library dropped from stable (and I'm entirely happy to agree!) then what needs to happen is the grisbi maintainer should check to see if it works with the new library. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in changelogs
Gunnar Wolf <[EMAIL PROTECTED]> writes: > Well... DJB was not trying to be specially nice Is DJB _capable_ of being nice?!? -Miles -- Quidquid latine dictum sit, altum viditur. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
Steve Langasek <[EMAIL PROTECTED]> writes: > How is this possible? By my count, this leaves us with one package using > each API. Wouldn't it be easier to port one of these packages to the new > API, instead of bloating oldlibs for such a niche library? How different of > an API are we talking about, after all? I don't know how different they are. I'd rather see the other package updated indeed. Feel free to mail the maintainer of grisbi (that's the other package) and tell him he should adapt to the new library. I don't know anything about grisbi. > Unless there's some other reason to do otherwise, I'd prefer to see the > transition to libofx1 in testing postponed until after sarge rather than > carry both versions around in a stable release. gnucash-1.8.10 requires the new libofx or I would have waited until after sarge anyway. Many users have clamored for gnucash-1.8.10 to be in sarge. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
On Mon, Jan 10, 2005 at 05:19:10PM -0800, Thomas Bushnell BSG wrote: > Santiago Vila <[EMAIL PROTECTED]> writes: > > IMHO, calling libofx0 the old library again is the wrong thing to do. > > The reason is explained in the changelog entry for libofx_0.6.2-6. > > A package compiled with the old (pre g++ 3.2) libofx0 library will > > not work with the "new" libofx0. > Yes; I did also make an upload under the name libofx that should > override the mistaken one and which has the old API. But I'd rather > have that retired. > > I still think the best thing to do would be to keep the old library > > name unchanged. This is the kind of stability our users expect. > > The new library already gives you the opportunity to get rid of the > > ugly c102 suffix, with time, is that is what you are looking for. > Fortunately there are only two users of libofx and one of them is me; > if this were something used by many people used I would worry a lot > more. The binary package should still be called libofx0c102, not libofx0. libofx0 would be fine as a source package name, but there's no reason to gratuitously change the name of the binary package. (Even though it's probably rare to find someone who still has a testing/unstable version of gnucash or grisbi on their system that's over 2 years old.) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: murphy is listed on spamcop
[EMAIL PROTECTED] (Marco d'Itri) writes: > It works as advertised, and the FAQ says that it should not be used to > block mail. Hmmm, I looked at the FAQ, and found this -- buried in the middle of a paragraph: "SpamCop encourages SCBL users to tag and divert email, rather than block it outright." Good advice to be sure (for any such service), but not very adamant. In any case, many clueless people _do_ use spamcop to block mail. I've had a number of email conversations with mailing lists admins who basically refused to stop using spamcop in this way, saying "If you're listed in spamcop, there _must_ be something fishy about your machine!" [Pointing out that it's not a good idea to use it this way usually results in the admin getting pissy "I'll do what I want! You suck!"] So in practice, it is often used as an absolute block. This is a problem. If one assumes that it's impractical to address this issue by talking to individual users of spamcop -- there are more of them, and many of them are idiots -- I think it's reasonable to ask what spamcop itself could do to help. Since the basic problem seems to be a mismatch between what spamcop is and what people _think_ spamcop is, I can imagine: (1) Spamcop could try to move users' perceptions closer to reality by being more forceful in educating users, e.g., put in giant blinking letters on their home page (and other places): "SPAMCOP IS NOT A RELIABLE SOURCE OF INFORMATION ABOUT SPAMMERS; _DO NOT USE IT TO BLOCK MAIL_" (2) Spamcop could try to move reality closer to users' perceptions by trying to provide more reliable information and applying stricter standards to the information it exports. -Miles -- "Though they may have different meanings, the cries of 'Ye-haw!' and 'Allahu akbar!' are, in spirit, not actually all that different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
On Mon, Jan 10, 2005 at 04:16:52PM -0800, Thomas Bushnell BSG wrote: > Santiago Vila <[EMAIL PROTECTED]> writes: > > I would reupload the old library ASAP using a version number higher > > than the current version in unstable, but in Section: oldlibs and > > without the -dev package. > > Then packages needing the new -dev package should definitely have to > > wait for the new library to exist in unstable. Including the library > > version in the -dev package name might help as well. It would force > > new uploads to change the Build-Depends. > Actually, since the new version is a new API, we should keep both > around because there are now users of both. How is this possible? By my count, this leaves us with one package using each API. Wouldn't it be easier to port one of these packages to the new API, instead of bloating oldlibs for such a niche library? How different of an API are we talking about, after all? Unless there's some other reason to do otherwise, I'd prefer to see the transition to libofx1 in testing postponed until after sarge rather than carry both versions around in a stable release. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: If *-module depends on *-utils, should *-source recommend it?
On Mon, Jan 10, 2005 at 05:36:50PM -0800, Steve Langasek wrote: > dpkg doesn't do this because this isn't how dpkg works -- people wrote a > higher-level tool, apt, to do that. People ignoring error messages from > their package manager, breaking their system's network interface, and > blaming the Debian maintainer are something of an edge case that isn't worth > dealing with. So why does apt exist? I mean, if people weren't such complete damn morons they'd simply eyeball all the dependencies they need and make sure they have them. Stupid people! For that matter, why does a package even bother listing its dependencies in a programmic way at all? Surely them stupid idiots can just read the README. Maybe the problem is that by design people are forced to use dpkg in this situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, Jan 11, 2005 at 11:15:26AM +1100, Cameron Hutchison wrote: > Once upon a time Steve Langasek said... > > > > There is nothing in the -source package that actually requires (or should > > recommend) the -utils package. A much better fix here is for people to get > > over the fact that dpkg isn't apt. > Apologies for continuing this but having read through the thread I still > dont think I understand the issue with dpkg in this situation. > Is the following scenario the issue here with dpkg? : > foo-modules_1.0 is installed. It is standalone and does not require any > other packages to be installed. > foo-modules_2.0 is built from foo-source. > foo-modules_2.0 depends on foo-utils. > User runs "dpkg -i foo-modules_2.0_arch.deb" > dpkg first removes foo-modules_1.0 > dpkg then check dependencies of foo-modules_2.0 > dpkg complains that foo-utils is not installed and aborts the > installation of foo-modules_2.0 You seem to have left out a step before this: "user is a moron and ran rmmod foo at this point, instead of reading the error message and running apt-get -f install or apt-get install foo-utils". If the dependencies of the foo-modules package are correct, this is the only way to get your system into such a broken state. If they aren't correct, adding the same incorrect dependencies to the -source package is irrelevant. > foo-modules is now in a broken state unable to be used. > Networking depends on foo-modules so it is not possible to install > foo-utils unless it is locally available. > Is this the scenario being argued over? If so, why does dpkg not first > check the dependencies of foo-modules_2.0 before removing > foo-modules_1.0? If not, could someone explain to me (or point me to a > resource) what the issue is? dpkg doesn't do this because this isn't how dpkg works -- people wrote a higher-level tool, apt, to do that. People ignoring error messages from their package manager, breaking their system's network interface, and blaming the Debian maintainer are something of an edge case that isn't worth dealing with. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: ok, i screwed up
Santiago Vila <[EMAIL PROTECTED]> writes: > IMHO, calling libofx0 the old library again is the wrong thing to do. > The reason is explained in the changelog entry for libofx_0.6.2-6. > A package compiled with the old (pre g++ 3.2) libofx0 library will > not work with the "new" libofx0. Yes; I did also make an upload under the name libofx that should override the mistaken one and which has the old API. But I'd rather have that retired. > I still think the best thing to do would be to keep the old library > name unchanged. This is the kind of stability our users expect. > The new library already gives you the opportunity to get rid of the > ugly c102 suffix, with time, is that is what you are looking for. Fortunately there are only two users of libofx and one of them is me; if this were something used by many people used I would worry a lot more. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
On Tue, 10 Jan 2005, Thomas Bushnell BSG wrote: > I've created libofx0 and libofx1 which are the old and new versions, > and ask the ftp-masters to drop the old package entirely. I'll > request the other user of libofx to adapt accordingly. IMHO, calling libofx0 the old library again is the wrong thing to do. The reason is explained in the changelog entry for libofx_0.6.2-6. A package compiled with the old (pre g++ 3.2) libofx0 library will not work with the "new" libofx0. I still think the best thing to do would be to keep the old library name unchanged. This is the kind of stability our users expect. The new library already gives you the opportunity to get rid of the ugly c102 suffix, with time, is that is what you are looking for. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LCC and blobs
Michael Poole <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG writes: > > > Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > > > > | This is a canonical example of a network-downloader package. > > > > > > No, they download something and unpacks it on a file system. They > > > don't feed the data they download into some device. > > > > So you think the key difference is whether the data downloaded lands > > on a hard drive instead of a flash rom? > > That is apparently an important distinction when it comes to where the > data is customarily stored; why should it be ignored for a download? I'm not saying it should be ignored; I'm saying its irrelevant to whether the downloader package belongs in contrib or main. Why do you care, incidentally? Why not just put the thing in contrib and be done with it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LCC and blobs
Thomas Bushnell BSG writes: > Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > > | This is a canonical example of a network-downloader package. > > > > No, they download something and unpacks it on a file system. They > > don't feed the data they download into some device. > > So you think the key difference is whether the data downloaded lands > on a hard drive instead of a flash rom? That is apparently an important distinction when it comes to where the data is customarily stored; why should it be ignored for a download? Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LCC and blobs
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > | This is a canonical example of a network-downloader package. > > No, they download something and unpacks it on a file system. They > don't feed the data they download into some device. So you think the key difference is whether the data downloaded lands on a hard drive instead of a flash rom? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MPEG in general Was: Is anyone packaging `lame' ?
I demand that Tollef Fog Heen may or may not have written... > * Chris Cheney >> Its all encumbered, there is a separate organization MPEG-LA that strictly >> deals with the licensing. It is quite surprising to me that ffmpeg was >> allowed into main. > According to rumors I heard, it was allowed in since other applications > (xine at least, I think) already included it. So it didn't really make a > difference -- if we're infringing on patents with ffmpeg, we are with xine > as well. http://cvs.sourceforge.net/viewcvs.py/xine/xine-lib/src/libffmpeg/> -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | We've got Shearer, you haven't Your education begins where what is called your education is over. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, Jan 11, 2005 at 11:15:26AM +1100, Cameron Hutchison wrote: > Is this the scenario being argued over? Yes, that was exactly what I had in mind >If so, why does dpkg not first > check the dependencies of foo-modules_2.0 before removing > foo-modules_1.0? "Because it's a low-level tool intended for experts" I suppose an expert may want to fulfill the dependency using a non-Debian install of the utilities and they want dpkg to allow this by default. In apt you have to -force this; in dpkg you don't. I guess it's to keep dpkg simple. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
Santiago Vila <[EMAIL PROTECTED]> writes: > I would reupload the old library ASAP using a version number higher > than the current version in unstable, but in Section: oldlibs and > without the -dev package. > > Then packages needing the new -dev package should definitely have to > wait for the new library to exist in unstable. Including the library > version in the -dev package name might help as well. It would force > new uploads to change the Build-Depends. Actually, since the new version is a new API, we should keep both around because there are now users of both. I've created libofx0 and libofx1 which are the old and new versions, and ask the ftp-masters to drop the old package entirely. I'll request the other user of libofx to adapt accordingly. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Once upon a time Steve Langasek said... > > There is nothing in the -source package that actually requires (or should > recommend) the -utils package. A much better fix here is for people to get > over the fact that dpkg isn't apt. Apologies for continuing this but having read through the thread I still dont think I understand the issue with dpkg in this situation. Is the following scenario the issue here with dpkg? : foo-modules_1.0 is installed. It is standalone and does not require any other packages to be installed. foo-modules_2.0 is built from foo-source. foo-modules_2.0 depends on foo-utils. User runs "dpkg -i foo-modules_2.0_arch.deb" dpkg first removes foo-modules_1.0 dpkg then check dependencies of foo-modules_2.0 dpkg complains that foo-utils is not installed and aborts the installation of foo-modules_2.0 foo-modules is now in a broken state unable to be used. Networking depends on foo-modules so it is not possible to install foo-utils unless it is locally available. Is this the scenario being argued over? If so, why does dpkg not first check the dependencies of foo-modules_2.0 before removing foo-modules_1.0? If not, could someone explain to me (or point me to a resource) what the issue is? Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
On Mon, Jan 10, 2005 at 03:35:07PM -0800, Steve Langasek wrote: > Oh, but wait, the version of ndiswrapper-source in testing is packaged by > the same maintainer, and it works just fine for me. Did you try building it against kernel 2.6.10? Old versionf of upstream debs build against new kernels; this version required a new release to support it > This is off-topic for this list. If you want to propagandize .deb packages > that come from non-Debian sources, try doing it somewhere that your opinion > is actually respected. At least one other person said it's true. I'm glad you find the inferior version acceptable. to you too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Tue, Jan 11, 2005 at 12:16:00AM +0100, Tollef Fog Heen wrote: > If you use dpkg -i, sure you do. dpkg is a low-level tool; treating > it as anything else will give surprising and annoying results. Maybe authors of package-generating packages should point out that they are only installable by a low-level and annoying tool. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Mon, Jan 10, 2005 at 05:17:19PM -0600, Matthew Dempsky wrote: > It seems like the common case for wanting to install a kernel module > source package is to build the module and then install it on the same > box. Since the *-source package doesn't really depend on *-utils, why > not add a Recommends line? > For example, ndiswrapper-source would Recommend ndiswrapper-util, > while ndiswrapper-module-* would Depend on ndiswrapper-util still. > (Similarly for alsa-*, and any other modules.) The build system may not be the same as the system where the package will be installed, or one may be a chroot of the other, in which case this is needless overhead. There is nothing in the -source package that actually requires (or should recommend) the -utils package. A much better fix here is for people to get over the fact that dpkg isn't apt. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]
On Mon, 10 Jan 2005 16:51:07 -0500, Glenn Maynard <[EMAIL PROTECTED]> wrote: > Again, by this logic, all software in contrib due to non-free library > dependencies should go in main; after all, they're "useful" for developing > and testing free reimplementations of those libraries. This is just an > argument for dropping contrib entirely and merging it back into main. The firmware download is an incidental function of the driver, and in almost all cases there are some versions or states of the hardware in which it can be skipped during the driver probe. (Probably there is some hardware to which this doesn't apply; obviously there's still a need for case-by-case analysis.) It's a different scenario from the usual "main source builds main and contrib binaries", in which the part that's, say, written in Java (and dependent on recent J2SDK bits) or linked against Oracle's client library doesn't belong in the main binary package. Given the factual context of the kernel, I think there's enough "constitutional" room to place the border between main and non-free right at the module-firmware boundary rather than mandate that the driver be in the "contrib" DMZ. But IANADD, and YMMV. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
On Mon, Jan 10, 2005 at 11:32:45AM -0500, William Ballard wrote: > On Mon, Jan 10, 2005 at 05:21:53PM +0100, Francesco P. Lovergine wrote: > > identify problems, both in upstream and packaged versions. Posting in > > d-d is at least inappropriate. > It's an open list. And streets are public, but you urinating in them is still inappropriate. > The problem is the upstream has the goal of producing a package that > works and another guy is trying to produce a package which requires > module-assistant and "looks like" other packages. Ah, you've nailed it here. Of course, the Debian maintainer had no intention of making a package that worked, it was all about making a showpiece... you've torn back the curtain of *this* little conspiracy. Oh, but wait, the version of ndiswrapper-source in testing is packaged by the same maintainer, and it works just fine for me. > Listen, I'm just going to say this and not reply to all the bazillion > other flames which are coming: > The upstream is better. It's already Debianized. Do not use the one in > the Debian archive. This is off-topic for this list. If you want to propagandize .deb packages that come from non-Debian sources, try doing it somewhere that your opinion is actually respected. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: LCC and blobs
* Thomas Bushnell BSG | Tollef Fog Heen <[EMAIL PROTECTED]> writes: | | > Imagine me having an USB device. The driver opens a network | > connection to firmware.example.com, sends the device identification | > string and gets another string. This one is sent to the USB device | > which then does what it's supposed to do. | | This is a canonical example of a network-downloader package. No, they download something and unpacks it on a file system. They don't feed the data they download into some device. | Such things normally go in contrib in Debian. Why does this differ significantly from the graphviz-client mentioned earlier? It sends some data and receives some data. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
* William Ballard | On Mon, Jan 10, 2005 at 08:33:02PM +0100, Tollef Fog Heen wrote: | > dpkg -I on the resulting package and looking at the depends? | | But you don't expect to do that for other packages. If you use dpkg -i, sure you do. dpkg is a low-level tool; treating it as anything else will give surprising and annoying results. | I have started to use temporary apt repositories instead of | dpkg -I which fixes my problem. And accepted that package- | generating packages do not Suggest dependencies of the generated | package. Ok, good. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RunDinstallHourly
Matt Zimmerman wrote: >On Mon, Jan 10, 2005 at 10:54:34PM +, Steve McIntyre wrote: >> Tollef Fog Heen wrote: >> > >> >The downside of doing this is the extra load on the autobuilder >> >network, so Debian might not want to do it because of that. >> >> It might affect the mirrors, too... > >It would only affect the mirrors if they polled (or were pushed) more >frequently; that frequency could remain the same even though packages were >installed more frequently. True, yes. Clearly it's something to be considered. On balance, I'm definitely in favour of more frequent runs of dinstall. More frequent mirror runs may make things more awkward (e.g. nightly mirrors syncing an inconsistent archive), but that's probably offsetable by making the mirror tools more intelligent. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
I said: > I would reupload the old library ASAP using a version number higher > than the current version in unstable [...] Or you could use the same version number but adding an epoch. For example, libofx version 1:0.6.6-3. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ok, i screwed up
On Mon, 10 Jan 2005, Thomas Bushnell BSG wrote: > So I uploaded a new version of libofx. The problem is that the new > version bumped the soname, and I forgot to change the binary package > name to suit. > > Then after I received a bug report alerting me to the error, I fixed > the package itself to have a correct package name. The corrected > package is now waiting for the ftp masters to add it to the override > file. > > But there is also the binary package hanging around from the original > mistaken upload. It collides with the new package, of course, because > both install the new library (under the new library name), and that's > a problem for the existing users of the old library, of course. > > What I *want* to have happen is for the clock to be reversed, but > that's not possible. :) So what is the correct way for me to fix my > mess, so that the old library version continues to be there, and the > new version can show up as well? I would reupload the old library ASAP using a version number higher than the current version in unstable, but in Section: oldlibs and without the -dev package. Then packages needing the new -dev package should definitely have to wait for the new library to exist in unstable. Including the library version in the -dev package name might help as well. It would force new uploads to change the Build-Depends. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
If *-module depends on *-utils, should *-source recommend it?
It seems like the common case for wanting to install a kernel module source package is to build the module and then install it on the same box. Since the *-source package doesn't really depend on *-utils, why not add a Recommends line? For example, ndiswrapper-source would Recommend ndiswrapper-util, while ndiswrapper-module-* would Depend on ndiswrapper-util still. (Similarly for alsa-*, and any other modules.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#289385: RFH: cdrtools -- searching co-maintainer for the package
On 10165 March 1977, Nico Golde wrote: >> Right. I've checked with my boss and he's happy. It helps that we're >> about to start opening up some of our code anyway, so any conflict >> would be disappearing. I'll start digging into the bugs shortly to >> help. > Have fun with the coordination together with joerg schilling > ;-P Such mails definitely do not help. If you have a problem with him - we dont care, but whats the reason to write it to a public list? -- bye Joerg Aqua mach mal man brain maxx: schon probiert das gibts ned pgpjWemsP2Mhx.pgp Description: PGP signature
Re: MPEG in general Was: Is anyone packaging `lame' ?
* Chris Cheney | Its all encumbered, there is a separate organization MPEG-LA that | strictly deals with the licensing. It is quite surprising to me that | ffmpeg was allowed into main. According to rumors I heard, it was allowed in since other applications (xine at least, I think) already included it. So it didn't really make a difference -- if we're infringing on patents with ffmpeg, we are with xine as well. (Apologies if xine is not the package I'm thinking about.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RunDinstallHourly
On Mon, Jan 10, 2005 at 10:54:34PM +, Steve McIntyre wrote: > Tollef Fog Heen wrote: > > > >FWIW, our experiences with Ubuntu shows that having fast dinstall > >cycles is very helpful. You can sit and codevelop with people > >uploading to the archive as you go and letting other people in on what > >you are doing rather than having private repositories or similar > >solutions. It's a variant of the «release often, release early» > >principle. > > > >The downside of doing this is the extra load on the autobuilder > >network, so Debian might not want to do it because of that. > > It might affect the mirrors, too... It would only affect the mirrors if they polled (or were pushed) more frequently; that frequency could remain the same even though packages were installed more frequently. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New stable version after Sarge
* "Marcelo E. Magallon" | Are you thinking of say, the installer? I certainly *hope* that the | installer is going to stay in the current status for at least another | release! Another "whoos, let us restart from scratch" won't be | welcome by anyone. And my hope is based on the fact that the new | installer is *good* (instead of just adequate, like b-f). | | Or is it the next big thing going on with the archive? | | We don't have to go from X.0 to (X+1).0 in 6 months. It's perfectly ok | to go from X.0 to X.1. Since you're mentioning X: we might want to move to X.org after sarge. That'll probably take a little time to work itself out. We'll lose apache 1.3 and switch to apache 2.x, that might take a little time. PostgreSQL 8 would be nice. PHP5, possibly. I would be surprised if we didn't move to Python 2.4 (or 2.5 or whatever the current version is then). A lot of those applications doesn't necessarily take a long time by themselves, but together, they form a large, complex OS which takes time to stabilize. | Ok, 6 months may be too fast for some people (and I still want to know | about concrete examples where this is true and why), how about 9 | months? I work at something between an online publisher and an ISP -- we develop our own solutions and aren't really interested in what is «at the bottom». It's a fairly standard LAMP setup and we want it to be stable. Having to upgrade twice a year would take up significant resources and certainly not be something we're interested in. Nine months would be a bit too much, twelve to eighteen months would be nice, probably closer to twelve than eighteen. (This is just intended as one example where six months would be too frequent releases, but 30-odd, which we're looking at for Sarge, is too much.) On the other hand -- we need to decide whether we want time-based releases. Other projects have had great successes with them, but they might not be right for Debian. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RunDinstallHourly
Tollef Fog Heen wrote: > >FWIW, our experiences with Ubuntu shows that having fast dinstall >cycles is very helpful. You can sit and codevelop with people >uploading to the archive as you go and letting other people in on what >you are doing rather than having private repositories or similar >solutions. It's a variant of the «release often, release early» >principle. > >The downside of doing this is the extra load on the autobuilder >network, so Debian might not want to do it because of that. It might affect the mirrors, too... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim." [ seen in ucam.chat ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help me test new pcmcia-cs
hi per, On Mon, Jan 10, 2005 at 04:00:00PM +0100, Per Olofsson wrote: > I've uploaded a new version of the pcmcia-cs package to experimental, > 3.2.8-2. This package has a lot of new features, including: this package seems to work for me without any major problems (so far, anyway...), and it in fact seems to have fixed a couple problems from which i was quietly suffering on my thinkpad. sean -- signature.asc Description: Digital signature
ok, i screwed up
So I uploaded a new version of libofx. The problem is that the new version bumped the soname, and I forgot to change the binary package name to suit. Then after I received a bug report alerting me to the error, I fixed the package itself to have a correct package name. The corrected package is now waiting for the ftp masters to add it to the override file. But there is also the binary package hanging around from the original mistaken upload. It collides with the new package, of course, because both install the new library (under the new library name), and that's a problem for the existing users of the old library, of course. What I *want* to have happen is for the clock to be reversed, but that's not possible. :) So what is the correct way for me to fix my mess, so that the old library version continues to be there, and the new version can show up as well? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RunDinstallHourly
Tollef Fog Heen wrote: > The downside of doing this is the extra load on the autobuilder > network, so Debian might not want to do it because of that. Unless we already have a lot of developers putting off an upload until another day, this is a non-issue, since the autobuilders begin as soon as a package hits incoming. -- see shy jo signature.asc Description: Digital signature
Re: RunDinstallHourly
* Steve Langasek | There are really very few concrete benefits I can see to increasing the | dinstall frequency, but one in particular is to speed up debian-installer | testing. Most other bugs don't require a full dinstall cycle to give people | a good idea whether they've been fixed, but the installer builds out of the | archive, which means that verifying the fixes for certain bugs *does* | require a dinstall pulse followed by a d-i and CD build. So stepping this | up to a higher frequency than once a day can help here, but stepping it up | so that dinstalls happen more frequently than CD builds can be completed | does not. FWIW, our experiences with Ubuntu shows that having fast dinstall cycles is very helpful. You can sit and codevelop with people uploading to the archive as you go and letting other people in on what you are doing rather than having private repositories or similar solutions. It's a variant of the «release often, release early» principle. The downside of doing this is the extra load on the autobuilder network, so Debian might not want to do it because of that. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Manpages licensed under GFDL without the license text included
On Mon, 10 Jan 2005 14:25:37 +1300 Nick Phillips wrote: > The fact that we have conveniently > ignored this problem when dealing with the GPL and BSD licenses so far > does not make it go away. It is my understanding that Debian packages refer to the GPL text in /usr/share/common-licenses/ because the GPL license requires us to *accompany* the compiled form with the license text, rather than going beyond and requiring that the license text be *included* in the compiled form (that is fairly more demanding). Similarly the BSD license (2, 3 or 4 clause version) requires: | 2. Redistributions in binary form must reproduce the above copyright |notice, this list of conditions and the following disclaimer in the |documentation and/or other materials provided with the ^ |distribution. As a tangent, it must be noted that /usr/share/common-licenses/BSD is usually not exploited as a target for license reference, as it is a particular (rather than general) instance of the 3-clause BSD license: it names "The Regents of the University of California" as the copyright holders... -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp9xXQm1jTKG.pgp Description: PGP signature
Re: remove me
Quoting Michelle Konzack ([EMAIL PROTECTED]): > rm -rf [EMAIL PROTECTED] >/dev/null Nope, you're definitely wrong. The correct command line should be: cd "call wave" ; rm -f [EMAIL PROTECTED] >/dev/null The user explicitely asked for being removed from call wave only.:) I'm pretty sure other fellow DD's will find nice ways to enhance this and correct my poor shell syntax, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]
On Mon, Jan 10, 2005 at 01:32:26PM -0800, Michael K. Edwards wrote: > All of them are useful for > developing and testing free firmware, as advocates of reverse > engineering have pointed out. Again, by this logic, all software in contrib due to non-free library dependencies should go in main; after all, they're "useful" for developing and testing free reimplementations of those libraries. This is just an argument for dropping contrib entirely and merging it back into main. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
On Mon, 2005-01-10 at 21:11 +0100, Wouter Verhelst wrote: > Op ma, 10-01-2005 te 13:24 -0600, schreef Ron Johnson: > > On Mon, 2005-01-10 at 19:14 +0100, Wouter Verhelst wrote: > > > Op ma, 10-01-2005 te 06:39 -0500, schreef David Mandelberg: > > [snip] > > > 'RTFM' means "Go read the documentation, that's what it's for". I > > > personally find it far more rude to go on a mailing list, ask for the > > > > Do you *really* think that RTFM means "Go read the documentation, > > that's what it's for"? > > I fail to see the point of this, but for the sake of the argument... > > Yes, I *really* think that RTFM means "Go read the documentation, that's > what it's for". Not literally, of course, but that's the message people > are sending you when they say "RTFM". You must be a diplomat, because when *I* write RTFM, I *mean* RTFM... -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "Your opinions are bound to affect the stories you choose to broadcast [on TV/radio]." signature.asc Description: This is a digitally signed message part
Re: rudeness in general
On Mon, 2005-01-10 at 20:28 +, Henning Makholm wrote: > Scripsit Ron Johnson <[EMAIL PROTECTED]> > > On Mon, 2005-01-10 at 19:37 +, Henning Makholm wrote: > >> Scripsit Ron Johnson <[EMAIL PROTECTED]> > > >> > Do you *really* think that RTFM means "Go read the documentation, > >> > that's what it's for"? > > >> Yes, that's what it means. > > > http://catb.org/~esr/jargon/html/R/RTFM.html > > You're confusing the historic origin of the letter combination with > its meaning in actual use. IMNSHO, RTFM still has an acerbic edge to it. If you want sweetness and light, just tell them which document to read. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. I like my women like a like my coffee: ground up and in the freezer. signature.asc Description: This is a digitally signed message part
Re: rudeness in general
On Mon, Jan 10, 2005 at 07:14:29PM +0100, Wouter Verhelst wrote : > Why don't you guys go to psychology class before telling people not to > be 'rude'? > It's impossible not to be rude on written media. What's a harmless joke > to one is an insult to another, and an attack to one's personality to a > third one. You can't expect everyone to be happy with everything you > might possibly write. Then what about keeping jokes for our private messages to our friends ? Your suggestion to go back to classes is, to my standards, definetly rude. As it does not add anything to your message, I do not understand why you want to take the risk to offend people, if there is no payback for it. > 'RTFM' means "Go read the documentation, that's what it's for". It also contains the "F word", which is related to the act of having sex. I wouldn't expect everybody to understand that using such a vocabulary has no mean to be instulting, as it is a hallmark of sentences which contain words about sex, feces or body parts to be more frequently insulting than average... As you say, any translation is sort of risky (even between related languages, where identical words have changed their meaning). My point of view is to minimise the risks when talking on international mail-lists, and in any case, to avoid anything which sounds like a personnal attack, including more general sentences which include the person you are answering to, as the first one of your mail... > I personally find it far more rude to go on a mailing list, ask for > the obvious, and expect a bunch of volunteers to come up with an > answer that's been answered in great detail in the documentation, > than to be sent back with an 'RTFM' as answer to that question. Silence is also an answer. And sometimes, volunteers do come up. > In any case, I strongly disagree with the stance that the rudeness of a > particular developer would reflect on Debian as a whole. Sure, people > who think they've been handled unfairly aren't going to talk positively > about Debian; but that happens to any organization, commercial or > voluntarily-based. That doesn't mean one rude developer will label > Debian as a rude organization... Most commercial organisations do their best to contrtol how their employees reflect their image, event to a point which is questionnable, when they want to take a tight control of physical appearance, or when they request people on phone hotlines to change their fisrt name because being called Mustapha is less correct that being called Pierre. The reason is they beleive that every invidual reflects the image of the organisation, especially at the first encounter. -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]
[whoops, hit "Send" instead of "Save Draft"] > I think the best way to be honest about that is to exclude non-free > firmware images from the kernel binary and modules themselves but to > permit loading them from the initrd or the root filesystem. Initrd > images in main shouldn't contain non-free firmware; initrd images in > non-free may (presuming that they are legitimately distributable), and > Debian's mkinitrd tools are available (and quite usable) for > sophisticated users to roll their own. The drivers, I think, still belong instead of main instead of contrib. Most of them will work to drive a "hot" device that has already had firmware fed to it. Many of them work with models of the hardware that have the firmware already in flash; it's just that some models omit the flash for cost reasons, or have a broken or DOS-only mechanism for permanent flash updates. All of them are useful for developing and testing free firmware, as advocates of reverse engineering have pointed out. Drivers for most hardware with not-very-firm firmware aren't like the NVidia driver, which loads a blob of host code containing most of the functionality. They don't present a QA obstacle worse than drivers for hardware containing flash. It's one thing to work towards a world in which hardware vendors have beaten their copyright swords into plowshares; it's another to run full-tilt into those swords when they're halfway to the forge, just to prove a point. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious problem with the tty terminal - HELP!
Hi, This should be debian-user question. On Mon, Jan 10, 2005 at 03:03:48PM +0100, Bjorn Johansson wrote: > I have a problem with the text (tty) terminals. The problem is that if I move > from the x-server to an tty text terminal I can't go back and I can't switch > to another tty terminal either. The only way to get back to X is to kill the > x-server. > > This problem has arised since I deleted all files i /lib. Then I reinstalled > the gnome and kde system with the apt tool. And I have also reinstalled > the base system, but it seems I've missed something, because this is not the > default behaviour after a fresh install. OK. Try again. :-) You still have X and xterm. > And when I mean a fresh install, I > mean installing from scratch with an empty harddisk. One idea is to use aptitude to re-install all the packages. You still have /var/cache. First, I suggest you to do back up of data. You may want to keep it. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#289385: RFH: cdrtools -- searching co-maintainer for the package
hi, * Steve McIntyre <[EMAIL PROTECTED]> [2005-01-10 22:12]: > On Sun, Jan 09, 2005 at 08:13:46PM +, Steve McIntyre wrote: > >>Unfortunately we dont have the time the package needs, so help is > >>needed. Ideally you should know a bit of C and of Debian Packaging. You > >>should also know cdrecord/mkisofs and its friends and of course have a > >>cd burner at home to test stuff. :) > >> > >>You do not need to be a DD to help out, just start by going through the > >>buglist, preparing patches, answering/closing them if needed, etc. pp. > > > >I'd love to help. I need to check that my employer would have no > >problem (I write proprietary storage software for a living!), so I'll > >get back to you tomorrow. > > > >I've already written several patches for mkisofs and cdrecord over the > >years I've been using them, so I'm quite experienced with the code. > > Right. I've checked with my boss and he's happy. It helps that we're > about to start opening up some of our code anyway, so any conflict > would be disappearing. I'll start digging into the bugs shortly to > help. Have fun with the coordination together with joerg schilling ;-P regards nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF ,'"`. [EMAIL PROTECTED] | http://www.ngolde.de ( grml.org VIM has two modes - the one in which it beeps`._,' and the one in which it doesn't -- encrypted mail preferred signature.asc Description: Digital signature
Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]
On Sun, 9 Jan 2005 22:01:52 -0800, Steve Langasek <[EMAIL PROTECTED]> wrote: > It is not enough to say that you *could* create free firmware files. As a > user of xpdf, I can unequivocally say that there are pdfs that I have full > rights to, because *I created them*. I cannot say that about firmware > files. If you have a free firmware file that works with the driver in > question, please produce it for us to see. It should become part of the > package immediately, and be loaded by default by the driver. > > If, on the other hand, we know that the driver needs to load firmware from > disk before it can actually be usable with any device, and we don't have any > real, working firmware images that are free, it is disingenuous to handwave > this away by saying that "free firmware could exist". We either have free > firmware for use with the device, or we don't. If we don't, then the driver > won't work for our users without additional effort, and we should be honest > about that. I think the best way to be honest about that is to exclude non-free firmware images from the kernel binary and modules themselves but to permit loading them from the initrd or the root filesystem. Initrd images in main shouldn't contain non-free firmware; initrd images in non-free may (presuming that they are legitimately distributable), and Debian's mkinitrd tools are available (and quite usable) for sophisticated users to roll their own. Depending on what happens at the day job, I may have a chance to put in some effort along those lines as I migrate their platform to 2.6.x kernels. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
On Mon, Jan 10, 2005 at 09:40:47PM +0100, Eduard Bloch wrote: > > How can a couple of variables (not two dozens that you would need to get > from the headers, environment and some other sources) mean tight > coupling? In which world are you living? Meaning it breaks it isn't there. You're confusing "coupling" with "cohesion." It has low cohesion, but it breaks if it isn't there so that's tight coupling. I agree. Let's drop it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
* William Ballast [Mon, Jan 10 2005, 02:34:15PM]: > > WTF? IIRC there are studies about where low cooupling and high cohesion > > make sense and where not. > > All he uses from your include files are a couple of variables. > That's low cohesion, tight coupling. How can a couple of variables (not two dozens that you would need to get from the headers, environment and some other sources) mean tight coupling? In which world are you living? Regards, Eduard. PS: Sorry, EOD. I don't have enough spare time to waste in a such discussion. -- der Aquariophile ist schon ein bot, oder ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
Scripsit Ron Johnson <[EMAIL PROTECTED]> > On Mon, 2005-01-10 at 19:37 +, Henning Makholm wrote: >> Scripsit Ron Johnson <[EMAIL PROTECTED]> >> > Do you *really* think that RTFM means "Go read the documentation, >> > that's what it's for"? >> Yes, that's what it means. > http://catb.org/~esr/jargon/html/R/RTFM.html You're confusing the historic origin of the letter combination with its meaning in actual use. -- Henning Makholm "Check the sprog." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Monday 10 January 2005 22:25, Wouter Verhelst wrote: > Op ma, 10-01-2005 te 15:12 -0500, schreef William Ballard: > > On Mon, Jan 10, 2005 at 08:33:02PM +0100, Tollef Fog Heen wrote: > > > dpkg -I on the resulting package and looking at the depends? > > > > But you don't expect to do that for other packages. > > You can also just run 'apt-get -f install' once the dependency breakage > occurs. That's what it's for. This should be the last one should try, e.g. break the things with dpkg -i and then try to fix them with apt-get install -f, what if you have just broke apt ... yes I know one can handle that, but why spending extra time in a-la rpm hell [tm] situations, which could be avoided easily... The right way [tm] is to place the resulting deb in a local apt repo and install & whatever from there exploring the advantages of apt. That's what it's for. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
Op ma, 10-01-2005 te 15:12 -0500, schreef William Ballard: > On Mon, Jan 10, 2005 at 08:33:02PM +0100, Tollef Fog Heen wrote: > > dpkg -I on the resulting package and looking at the depends? > > But you don't expect to do that for other packages. You can also just run 'apt-get -f install' once the dependency breakage occurs. That's what it's for. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Mon, Jan 10, 2005 at 08:33:02PM +0100, Tollef Fog Heen wrote: > dpkg -I on the resulting package and looking at the depends? But you don't expect to do that for other packages. I have started to use temporary apt repositories instead of dpkg -I which fixes my problem. And accepted that package- generating packages do not Suggest dependencies of the generated package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
Op ma, 10-01-2005 te 13:24 -0600, schreef Ron Johnson: > On Mon, 2005-01-10 at 19:14 +0100, Wouter Verhelst wrote: > > Op ma, 10-01-2005 te 06:39 -0500, schreef David Mandelberg: > [snip] > > 'RTFM' means "Go read the documentation, that's what it's for". I > > personally find it far more rude to go on a mailing list, ask for the > > Do you *really* think that RTFM means "Go read the documentation, > that's what it's for"? I fail to see the point of this, but for the sake of the argument... Yes, I *really* think that RTFM means "Go read the documentation, that's what it's for". Not literally, of course, but that's the message people are sending you when they say "RTFM". -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
On Mon, 2005-01-10 at 19:37 +, Henning Makholm wrote: > Scripsit Ron Johnson <[EMAIL PROTECTED]> > > > Do you *really* think that RTFM means "Go read the documentation, > > that's what it's for"? > > Yes, that's what it means. Well, that's what I'd tell my grandmother that it means... http://catb.org/~esr/jargon/html/R/RTFM.html -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "Today's public figures can no longer write their own speeches or books, and there is some evidence that they can't read them either." Gore Vidal signature.asc Description: This is a digitally signed message part
Re: rudeness in changelogs
Steve Greenland dijo [Sat, Jan 08, 2005 at 06:44:24PM -0600]: > > Is this really called for in changelogs? Note that the bug reports were > > perfectly polite. > > Not really called for, but I understand the frustration with people who > have nothing better to do than nag, and (for the second bug) without > even checking the existing bugs! Remember that, although it is expected from seasoned Debian users and developers to do this, there is no hard requisite on not duplicating bug reports. After all, you as the maintainer can merge them. It is nicer if the user saves you the work, but anyway, he is not required to do it. > > Imagining myself as a student in this class: I complete the requested > > assignment, with luck make an A, only to have the prof post it to the > > internet and then be insulted by perfect strangers as they use my work > > to fix their problems. > > These would be the same students who didn't even have the minimum > decency to attempt to notify the upstream authors before publishing > the bugs? I think taking a dig at them in the changelog is the *least* > anyone should do. Well... DJB was not trying to be specially nice - Quite the contrary. Take a look at the thread [1], specially at DJB's [2] and his student's [3] messages (specially [3], it illustrates the point better). DJB's class was not about "helping Free Software authors", it was about punishing developers who write buggy software, about showing that Free Software is inherently no better than propietary software. There is a nice debate in the thread. Greetings, -- [1] http://www.securityfocus.com/archive/1/384661/2004-12-15/2004-12-21/0 [2] http://www.securityfocus.com/archive/1/384888/2004-12-15/2004-12-21/0 [3] http://www.securityfocus.com/archive/1/385206/2004-12-22/2004-12-28/0 -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
10.01.2005 pisze Ron Johnson ([EMAIL PROTECTED]): > > 'RTFM' means "Go read the documentation, that's what it's for". I > > personally find it far more rude to go on a mailing list, ask for the > Do you *really* think that RTFM means "Go read the documentation, > that's what it's for"? If one has the skin not thick enough to read the proper meaning from RTFM, one should not use mailing lists and should concentrate on dead tree repositories. Being oversensitive in public is usually counterproductive. Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] God is real, unless declared integer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
Scripsit Ron Johnson <[EMAIL PROTECTED]> > Do you *really* think that RTFM means "Go read the documentation, > that's what it's for"? Yes, that's what it means. -- Henning Makholm "They discussed old Tommy Somebody and Jerry Someone Else." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
* William Ballard | Tell my why you'd ever want ndiswrapper-utils and not | ndiswrapper-source. Then tell me if that's the most common | case. Because my distributor ships the ndiswrapper.ko driver in the linux-restricted-modules (iirc) package. | Just tell me how you work around this problem and I'm having, | and I'll shut up. That's what I told the maintainer and he | never responded. | | Just tell me how I'm supposed to "just know" to get -utils? | Wait until it breaks? dpkg -I on the resulting package and looking at the depends? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
On Mon, Jan 10, 2005 at 07:59:59PM +0100, Eduard Bloch wrote: > WTF? IIRC there are studies about where low cooupling and high cohesion > make sense and where not. All he uses from your include files are a couple of variables. That's low cohesion, tight coupling. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
On Mon, 2005-01-10 at 19:59 +0100, de Bladen wrote: > In the meantime, begin to recompile Debian with staticaly linked > packages. That is very important, you know. That evil libc causes such a > mess of tight coupling, one could become crazy from just imaging all the > possible consequences!!!1 What?!!! You mean Debian Isn't statically linked for everything? OMG, SCO will be happy to know their plan worked! -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: rudeness in general
On Mon, 2005-01-10 at 19:14 +0100, Wouter Verhelst wrote: > Op ma, 10-01-2005 te 06:39 -0500, schreef David Mandelberg: [snip] > 'RTFM' means "Go read the documentation, that's what it's for". I > personally find it far more rude to go on a mailing list, ask for the Do you *really* think that RTFM means "Go read the documentation, that's what it's for"? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "I need an expert on the pain I'm goin' thru, so I keep George on the ol' turn table 'till I'm over you..." Mark Chesnutt, "Just Playin' Possum" signature.asc Description: This is a digitally signed message part
Re: remove me
rm -rf [EMAIL PROTECTED] >/dev/null done. Am 2005-01-10 13:49:57, schrieb [EMAIL PROTECTED]: > remove me from call wave. thank you - ENE OF REPLYED MESSAGE - Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: remove me from call*wave
from:[EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
#include * William Ballard [Mon, Jan 10 2005, 12:40:12PM]: > The only thing it "has to have" module-assistant is a couple of > variables in debian/rules. For that trivial advantage we now have tight > coupling on the rest of module-assistant, which means if those variables > change in module-assistant every other package has to change as well. WTF? IIRC there are studies about where low cooupling and high cohesion make sense and where not. > Loose coupling is better than tight coupling. ROTFL Dude, what did you read in the software engineering classes? Comic books? Please visit a Software Product Lines courses before spreading more crap (and maybe something about databases to learn the meaning of ACID). In the meantime, begin to recompile Debian with staticaly linked packages. That is very important, you know. That evil libc causes such a mess of tight coupling, one could become crazy from just imaging all the possible consequences!!!1 Regards, Eduard. -- Russian roulette for linux: [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "Still breathing, eh?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System snapshots
[Andrew Suffield] > Seems like a poor reimplementation of a backup system to me. It's > independently useful, and gains nothing from being embedded into the > package manager, so why stuff it into the package manager? I recommend reading the article, to gain some insight into the problem it is trying to solve. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LCC and blobs
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > Imagine me having an USB device. The driver opens a network > connection to firmware.example.com, sends the device identification > string and gets another string. This one is sent to the USB device > which then does what it's supposed to do. This is a canonical example of a network-downloader package. Such things normally go in contrib in Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PHP application packaging policy/best practice?
Kees Leune dijo [Fri, Jan 07, 2005 at 02:19:18PM +0100]: > Hi, > > I am preparing an ITP for a PHP application that is currently under > development at my place of employment. While thinking about packaging > it, I was wondering if there is any PHP application policy or best > practice. I am now leaning to a setup as follows: > (...) > Note that I chose /usr/lib over /usr/share because according to the > FHS, /usr/share is meant for "all read-only architecture independent > data files". Although PHP files are read-only and architecture > indepedent, I consider them as programs. Some people have pointed out that other PHP programs go to /usr/share as well. Just to complement: Perl modules also get installed to /usr/share if they are not architecture-specific. Python seems not to be that way, as its standard sys.path does not include /usr/share/*. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
remove me
remove me from call wave. thank you
Re: System snapshots
|| On Mon, 10 Jan 2005 18:08:02 + || Andrew Suffield <[EMAIL PROTECTED]> wrote: >> Such feature would be nice to have in Debian as well. If you have a >> very short upgrade window, where one will have to abort and roll back >> if the upgrade fail, it would be helpful if dpkg would allow you to >> roll back the upgrade. as> Seems like a poor reimplementation of a backup system to me. It's as> independently useful, and gains nothing from being embedded into the as> package manager, so why stuff it into the package manager? Well, I think transactions inside of package manager could be good because if one upgrade fail (mostly in sid environments) you can leave the all system in bad shape. as> Personally, I've been use dm-snapshot to cover system upgrades as> lately... Sure this works but it's not a snapshot like was suggested at begining of this thread. This works mostly like a "backup" :-) To me it's enough. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." pgpvKvRS6m5t0.pgp Description: PGP signature
Re: New stable version after Sarge
Florian Weimer wrote: > > Re: Paul van der Vlis in <[EMAIL PROTECTED]> > >> You will understand that my most important point is security-support. > > > > ...which Debian provides for its stable distribution at any time, even > > if the last stable release was ages ago. > > Where is the security support for woody's version of Mozilla, Samba > and PHP? Mozilla is a nightmare nobody can support - sadly. Samba is security-supported, the fix is pending though, but will be released soon. PHP is security supported and Debian is not vulnerable to the real vulnerabilities (CAN-2004-1019 and CAN-2004-1065), problems caused by faulty scripts are not considered an issue (and we'd have to issue a PHP updated every second day otherwise). I can only hope that the situation with Mozilla, Firefox, Galeon, Thunderbird and $whatnot will be better in sarge, but I have doubts. Regards, Joey PS: http://www.debian.org/security/nonvulns-woody#CAN-2004-1019 http://www.debian.org/security/nonvulns-woody#CAN-2004-1065 -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System snapshots
|| On Mon, 10 Jan 2005 18:40:39 +0100 || Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: pr> [Otavio Salvador] >> No because some applications doesn't depends only of configuration >> files but data-files. When you purge then, all data files will be >> removed together (in major of times). Another problem is how you can >> revert upgrade processes in database files and like? pr> RPM have a feature allowing it to do upgrade transactions and rollback pr> of failed installs, where it will include the data files in the pr> transaction log. I read about this in the Linux Journal article pr> "Transactions and Rollback with RPM" by James Oden, pr> http://www.linuxjournal.com/article/7034>. pr> Such feature would be nice to have in Debian as well. If you have a pr> very short upgrade window, where one will have to abort and roll back pr> if the upgrade fail, it would be helpful if dpkg would allow you to pr> roll back the upgrade. Rollback upgrade is more simple then allow snapshot. Let me try to clear what I think about it: If you want to allow rollback, you can do it using one transation to all involved packages with versioned depends and not ALL packages. Another issue is it will be available while you are upgrading and not later. Support it for later time is a lot more complicated because the data involved can be changed and you can't only revert to old data. You need to convert all changes to previous data. ie: PostgreSQL -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." pgpknuiuJ9IDv.pgp Description: PGP signature
Re: LCC and blobs
* Raul Miller | On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote: | > However, if somebody writes a graphviz-client which just pushes the | > dot file over the network to graphviz.example.com on some port and | > gets a postscript file back, it can go into main. No matter what | > software said server is running. Correct? | | In essence, yes. Let us take it a little further. Imagine me having an USB device. The driver opens a network connection to firmware.example.com, sends the device identification string and gets another string. This one is sent to the USB device which then does what it's supposed to do. Would the driver and anything depending on it still be free? (Let's assume the driver is GPL-ed or BSD-licensed or whatever makes you happy.) | Do you have a problem netcat being in main? I'm exploring the boundaries, I'm not making any sort of accusations or «having a problem» with anything. Not yet, at least. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289722: ITP: kde-systray2 -- KDE systray applet with icon hiding support
Package: wnpp Severity: wishlist * Package name: kde-systray2 Version : 0.51 Upstream Author : Georges A.K. <[EMAIL PROTECTED]> * URL : http://www.kde-look.org/content/download.php?content=17732 * License : GPL Description : KDE systray applet with icon hiding support This is the KDE System Tray with icon hiding support. It works exactly like the original tray but adds icon hiding support, smooth scrolling and icon grouping. (Some of this functionality will be available in KDE 3.4, but it is much too nice to stay 3 years without :-) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
