Re: possible grave bug in debian-installer or ifupdown?
Anthony Towns schrieb: >> I checked >> /etc/network/interfaces on both boxes and noticed the following line: >> allow-hotplug eth0 >> after replacing it with >> auto eth0 > > allow-hotplug interfaces will only be brought up by hotplug (or manually); > you might've deinstall hotplug and replaced it with udev, which would > probably give that result. The main point is: I've taken the latest Testing-CD installed Debian, updated it and that's it. I don't remember having intentionally replaced hotplug by udev or something, if this happened it must have happened automatically. This somehow feels like either d-i or ifupdown are broken by default so close before etch becomes stable. By the way: I've played around with quemu and the new d-i a few weeks ago and noticed that the resulting Debian/testing system did not bring up the interface too. >> I wonder if this is a bug in d-i or ifupdown. > > If you're not using hotplug, using "allow-hotplug" is the bug. But who has created the allow-hotplug-line? I thought hotplug is dead? Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#403506: ITP: fdisk -- linux fdisk replacement based on libparted
On Sun, Dec 17, 2006 at 10:58:29PM +0100, Julien Louis wrote: > I'll rename the package to gnu-fdisk reflect binary name changes. The usual naming scheme seems to be to prepend the name with a `g', see glibc, gcc, gawk, etc. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
block device served over network connections
DDs, I am looking for some info on this subject. I have looked at both the aoetools and open-iscsi for a solution to the following problem. I have a block device that is served over aoe. Basically, I would like to take two of these devices (e0.0 and e1.0) and create a raid1 with software RAID. However, I am not really sure how to solve this one. I am emailing here because I think the infrastructure to do such a thing may not exist in Debian. The basic problem is the network devices that receive info related to the block device must be up early enough that the mdadm discovery has not happened. It would be fairly easy to right a script that simply does "ifconfig eth0 up" and performs discovery (additionally disabling /etc/rcS.d/S41aoetools and essentially doing my own thing), but I would like to know if there is official Debian infrastructure for this sort of thing. Are there any other packages I should be looking at to make this happen? If not, maybe this is something that should be considered by some people who care as network based block storage is getting more common. With NBD, AOE, and ISCSI (and others I am sure), I don't think that each package should implement their own way of dealing with this problem, and I hope some kind of normalized way of dealing with this problem can be made available, if it is not already available. Thanks, wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#403506: ITP: fdisk -- linux fdisk replacement based on libparted
On Mon, 18 Dec 2006, Michael Banck wrote: On Sun, Dec 17, 2006 at 10:58:29PM +0100, Julien Louis wrote: I'll rename the package to gnu-fdisk reflect binary name changes. The usual naming scheme seems to be to prepend the name with a `g', see glibc, gcc, gawk, etc. and so gdisk (because g follows f in alphabethical order) sounds as a good name as successor of fdisk. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#403506: ITP: fdisk -- linux fdisk replacement based on libparted
Hello! On Mon, 18 Dec 2006 09:50:10 +0100, Michael Banck wrote: > On Sun, Dec 17, 2006 at 10:58:29PM +0100, Julien Louis wrote: >> I'll rename the package to gnu-fdisk reflect binary name changes. > > The usual naming scheme seems to be to prepend the name with a `g', > see glibc, gcc, gawk, etc. I think the main problem here is that the GNU fdisk page [1] already refers to another gfdisk, which AFAIK should be the GNOME fdisk, lately renamed to gnome-fdisk [2]. Thx, bye, Gismo / Luca Footnotes: [1] http://www.gnu.org/software/fdisk/ [2] http://live.gnome.org/ListOfCVSModulesArchive pgpeZOqBNFrAE.pgp Description: PGP signature
Bug#403584: RFH: apt-cacher -- caching proxy system for Debian package and source files
Package: wnpp Severity: normal I request assistance with maintaining the apt-cacher package. It needs a Perl coder with sufficient knowledge about network programming and HTTP protocol AND lots of spare time to test the fixes. And/Or help developing or rewritting the incomplete designated successor, apt-cacher-ng (currently C++ with some sugar). Eduard. The package description is: Apt-cacher performs caching of .deb and source packages which have been downloaded by local users. It is most useful for local area networks with slow internet uplink. . When a package is requested, the cache checks whether it already has the expected version, in which case it sends the package to the user immediately. If not, it downloads the package while streaming it to the user at the same time. A local copy is then kept for use by other users. . Apt-cacher has been optimized for best utilization of network bandwith and efficiency even on slow low-memory servers. Multiple ways of installation are possible: as a stand-alone HTTP server, as a daemon executed by inetd or as a CGI program. The client machines are configured by changing APT's proxy configuration or modification of access URLs in sources.list. . The package includes utilities to clean the cache (removing obsolete package files), to generate usage reports and import existing package files. Experimental features include a simple package checksum verification framework and pre-fetching of new packages (upgrade candidates). . Apt-cacher can be used as a replacement for apt-proxy, with no need to modify clients' /etc/apt/sources.list files (and even reusing its config and cached data), or as an alternative to approx. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.1 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible grave bug in debian-installer or ifupdown?
Hello! On Mon, 18 Dec 2006 07:36:01 +0100, Anthony Towns wrote: > On Sun, Dec 17, 2006 at 09:58:48PM +0100, Bastian Venthur wrote: >> I issued: >> # ifup eth0 >> manually on both boxes but nothing happened. > > This probably means that ifup thought the interface was already up > -- ie there was an "eth0" entry in /etc/network/ifstate. Shouldn't ifup show a message anyway? On my sid: = [EMAIL PROTECTED]:~$ cat /etc/network/run/ifstate lo=lo wired=wired-unige-sciii [EMAIL PROTECTED]:~$ sudo ifup wired Password: ifup: interface wired already configured [EMAIL PROTECTED]:~$ = Thx, bye, Gismo / Luca pgpfOGUJQ7a8e.pgp Description: PGP signature
Is bug #399214 release critical? (Upgrade from version not in debian currently)
Is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399214 release critical? The version of solfege in etch fails to upgrade from a version that does _not exist_ in neither stable, testing or sid now. It was a version that earlier was in testing, but has been replaced by a more recent version. -- Tom Cato Amundsen <[EMAIL PROTECTED]> http://www.solfege.org/ GNU Solfege - free ear traininghttp://www.gnu.org/software/solfege/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
On Sun, Dec 17, 2006 at 06:07:18PM -0400, Jose Luis Rivas Contreras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I'm maintaining libtorrent package, this source builds 2 binaries, > libtorrent-rakshasa (is libtorrent9 last version in debian archive) and > libtorrent-rakshasa-dev (is libtorrent9 last version in debian archive), > I get this warning from lintian when I build the package. > > Now running lintian... > W: libtorrent-rakshasa: package-name-doesnt-match-sonames libtorrent10 > Finished running lintian. > > The version I'm building is libtorrent-0.11.0 so I don't think I should > call the binary libtorrent10. Please check the real soname with objdump -p libtorrent-0.11.0 |grep SONAME Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is bug #399214 release critical? (Upgrade from version not in debian currently)
I think such bugs can be easily closed. Regards Daniel Tom Cato Amundsen <[EMAIL PROTECTED]> writes: > Is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399214 release > critical? > > The version of solfege in etch fails to upgrade from a version that does > _not exist_ in neither stable, testing or sid now. It was a version that > earlier was in testing, but has been replaced by a more recent version. > -- > Tom Cato Amundsen <[EMAIL PROTECTED]> http://www.solfege.org/ > GNU Solfege - free ear traininghttp://www.gnu.org/software/solfege/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is bug #399214 release critical? (Upgrade from version not in debian currently)
On Mon, Dec 18, 2006 at 12:55:47PM +0100, Daniel J. Priem wrote: > I think such bugs can be easily closed. > I disagree. If it was previously in testing, it could conceivably have been removed without the user noticing. In which case, it would be acceptable for the user to expect that the upgrade would be handled. Now, if there were a way to notify users of packages removed for buginess or whatever and advising them to remove the packages, you might have a point. However, the user at no time, AFAICT, was notified that removal of the package would be a good idea. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: arches and etch
On 3 Nov 2006, at 5:30 pm, Steinar H. Gunderson wrote: On Fri, Nov 03, 2006 at 04:55:04PM +, Tim Cutts wrote: The 486 was the first CPU in the X86 family to have an integral FPU. Only the 486DX; the 486SX didn't. Being thoroughly pedantic, yes it did, but it was disabled in the hardware. When you installed a 487, it disabled your 486SX completely, and you were effectively running with a normal 486. A more interesting question is when Intel finally integrated the 86 and 87 processors; as I understand it, the 486 was effectively just a 386 and 387 in a single package; the regions of silicon were still quite discrete. I'd heard that that situation lasted for some time, but I don't know when they were properly integrated. It's kind of like Intel's new so-called four-core chips, which are basically just two of the current dual-core CPUs in a single package (which has interesting implications for memory contention issues, which led to some interesting discussions at SC06 last month) (Are we offtopic now? :-) ) Oh yeah! :-) Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils [was: Re: Upgrading the priority of ucf]
On 6 Nov 2006, at 9:26 am, Josselin Mouette wrote: Le jeudi 02 novembre 2006 à 05:22 -0800, Josh Triplett a écrit : I would suggest b); reducing the "standard" set of packages seems like a feature, it won't break upgrades (if installed, the package will stay installed), and new installs don't need to get nfs-kernel-server as part of the *default* install. We're not talking about the NFS server, but of the NFS client. And a working NFS client is surely something we want as part of the default install. If someone wants to run an nfs server, they can install an nfs server package, either nfs-kernel-server or nfs-user-server (no good reason to prefer one to the other). nfs-user-server is deprecated. I think we shouldn't even ship it at all. I still use it on some real-world servers, but I can't now remember why. I definitely found something which only worked with the userland server. Wish I could remember what it was, but since the machines in question are production servers, I'm not about to mess with them to find out... Tim
Re: Downgrading the priority of nfs-utils
On 7 Nov 2006, at 3:40 am, Goswin von Brederlow wrote: Roger Leigh <[EMAIL PROTECTED]> writes: Josselin Mouette <[EMAIL PROTECTED]> writes: Le jeudi 02 novembre 2006 à 05:22 -0800, Josh Triplett a écrit : I would suggest b); reducing the "standard" set of packages seems like a feature, it won't break upgrades (if installed, the package will stay installed), and new installs don't need to get nfs-kernel-server as part of the *default* install. We're not talking about the NFS server, but of the NFS client. And a working NFS client is surely something we want as part of the default install. What's the rationale for needing it as part of the default install? The majority of the Debian (and GNU/Linux systems in general) I see tend to not use NFS at all. Do we have any usage statistics for the NFS client? But wouldn't you be surprised if "mount -tnfs server:/path /local/path" suddenly wouldn't work anymore in a fresh install? And I'm not sure that you are right with your majority claim. A lot of larger installations use nfs and they quickly add up to a lot of systems rivaling the rest of the user base in numbers. Perhaps it's time I installed popcon on the 1000+ Debian systems I maintain as part of my job... :-) Tim
Re: Downgrading the priority of nfs-utils
On 7 Nov 2006, at 11:17 pm, Brian May wrote: "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED] tuebingen.de> writes: Goswin> But wouldn't you be surprised if "mount -tnfs server:/path Goswin> /local/path" suddenly wouldn't work anymore in a fresh Goswin> install? Not really, no. I would be more surprised if it did work. NFS has a reputation of being insecure. I am not aware of any organisations, big/small, that use NFS any more except on restricted sets of computers. Er, here. Global NFS home directories. And at the last place I worked. And the place before that. Oh, actually, in every single place I've worked for the past 10 years. I suppose you could claim the set of machines running NFS is restricted in that it's behind a firewall, but that's the only sense. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted attr 1:2.4.32-1.1 (source amd64)
Andreas Barth a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Format: 1.7 > Date: Mon, 18 Dec 2006 13:42:31 + > Source: attr > Binary: libattr1 attr libattr1-dev > Architecture: source amd64 > Version: 1:2.4.32-1.1 > Distribution: unstable > Urgency: emergency > Maintainer: Nathan Scott <[EMAIL PROTECTED]> > Changed-By: Andreas Barth <[EMAIL PROTECTED]> > Description: > attr - Utilities for manipulating filesystem extended attributes > libattr1 - Extended attribute shared library > libattr1-dev - Extended attribute static libraries and headers > Closes: 403585 403590 403592 403599 403601 > Changes: > attr (1:2.4.32-1.1) unstable; urgency=emergency ^ Why such an urgency? AFAIK only unstable was affected, so there is no need to push the package to testing as soon as possible. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please let mplayer into testing
[actually, my original mail had to go to d-release, but I miss-auto-completed the To:] Bill Allombert ha scritto: > On Tue, Dec 12, 2006 at 11:09:09PM +0100, A Mennucc wrote: >> anyway, shortly after I wrote that email, the situation reverted again >> (for worse); so currently there is no agreement between me and Aurelien, >> and I put that matter to d-ctte, in bug 402772 the d-ctte, and all other people, settled for this final agreement - the bug 395252 should stay RC , but - the bug is though 'etch-ignore' > If you need an example of massive code duplication between > security-sensitive packages, I offer iceweasel and icedove: > > LANG=C diff -sr icedove-1.5.0.8.dfsg1/build-dir/mozilla/ iceweasel-2.0+dfsg/ > | grep "are identical"|wc -l > 21131 > > So there are at least 21131 fully duplicated files between this two > packages. thanks for the tip I agree with you... moreover, iceweasel/firefox , icedove/thunderbird , etc etc , have been a frequent source of security problems indeed this kind of argument was already presented in the discussion of the bug 395252 , but it did not work it seems that MPlayer is kind of a lighting rod for criticism and strong feelings a. signature.asc Description: OpenPGP digital signature
Need help with RC #396817
Hi, #396817 was reported back in November. Ian Lynagh, maintainer of GHC, and I both believe that the build was proceeding normally and that on the platform in question, it is not unreasonable to expect it to take quite a bit of time to compile that file. I have tried, in vain, to figure out someone to tweak the powerpc buildd to have a longer timeout. I was told to contact Daniel Jacobowitz, who told me to ask Ryan Murray. I wrote to Ryan on Dec. 6, and have not yet heard back from him. This seems like a very simple thing, and I'm frustrated that this package is being kept out of etch. Could someone: 1) Fix the autobuilder so this doesn't keep happening? 2) At least build and upload this package? Thanks, -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403619: RFP: languagetool -- rule-based language checker
Package: wnpp Severity: wishlist Package name: languagetool Version: 0.8.6 Upstream Author: Daniel Naber (naber at danielnaber de) URL: http://www.danielnaber.de/languagetool License: Mostly LGPL, also some BSD, Creative Commons Attribution ShareAlike 2.0 Description: A rule-based language checker This is a rule-based language checker for which a rule is defined. It can detect errors that a simple spell checker cannot detect e.g. mixing up there/their, no/now etc. It can also detect a limited amount of grammar mistakes. It currently has support for English, German, Polish, and Dutch, and limited support for French, Spanish, and Italian. It can be used standalone, as plugin for openoffice.org, with LyX, in java applications and as standalone web server. I think this would be a useful thing to have in Debian, since we currently don't seem to have something simular. But I have no intention to package this myself. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted attr 1:2.4.32-1.1 (source amd64)
* Aurelien Jarno ([EMAIL PROTECTED]) [061218 15:28]: > Andreas Barth a écrit : > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Format: 1.7 > > Date: Mon, 18 Dec 2006 13:42:31 + > > Source: attr > > Binary: libattr1 attr libattr1-dev > > Architecture: source amd64 > > Version: 1:2.4.32-1.1 > > Distribution: unstable > > Urgency: emergency > > Maintainer: Nathan Scott <[EMAIL PROTECTED]> > > Changed-By: Andreas Barth <[EMAIL PROTECTED]> > > Description: > > attr - Utilities for manipulating filesystem extended attributes > > libattr1 - Extended attribute shared library > > libattr1-dev - Extended attribute static libraries and headers > > Closes: 403585 403590 403592 403599 403601 > > Changes: > > attr (1:2.4.32-1.1) unstable; urgency=emergency > ^ > > Why such an urgency? AFAIK only unstable was affected, so there is no > need to push the package to testing as soon as possible. Because the documentation of this field tells me that urgency tells how important it is for people to install this upgrade. I probably wouldn't have choosen this value unless I was sure it won't propagate to testing so fast, though - but as testing migration is blocked currently anyways, I thought using the documented syntax is not wrong. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: block device served over network connections
> Are there any other packages I should be looking at to make this happen? > > If not, maybe this is something that should be considered by some people > who care as network based block storage is getting more common. With NBD, > AOE, and ISCSI (and others I am sure), I don't think that each package > should implement their own way of dealing with this problem, and I hope > some kind of normalized way of dealing with this problem can be made > available, if it is not already available. Looks like a word for using ubuntu's upstart instead of sysvinit ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug is very vague, should I close it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Finney escribió: > Jose Luis Rivas Contreras <[EMAIL PROTECTED]> writes: [...] >> >> So, should I close this bug? There's a lot of bugs requesting >> specific features[1] so I don't think this bug it's necessary. > > You could enlist the bug submitter's help. Ask them to retitle the bug > and be more specific about a particular feature, or to close it and > submit separate wishlist bugs for each feature they want. > So I will close the bug since all the features are already requested in another wishlist bugs. Thanks!! - -- ghostbar @ linux/debian 'unstable' on i686 - Linux Counter# 382503 http://ghostbar.ath.cx/ - irc.freenode.net #talug #velug #debian-es http://debianvenezuela.org.ve - irc.debian.org #debian-es #debian-ve CHASLUG -- http://chaslug.org.ve - irc.unplug.org.ve #chaslug San Cristobal - Venezuela. TALUG -- http://linuxtachira.org Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFhq8EOKCtW8rKsRgRAjlgAKCuqnyeHA1b44sGJKxPem8ogQFqmwCdEIK9 7JaeIq6lvHejrmNO9JB9RaU= =RENe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible grave bug in debian-installer or ifupdown?
On Mon, Dec 18, 2006 at 09:23:13AM +0100, Bastian Venthur wrote: > But who has created the allow-hotplug-line? I thought hotplug is dead? Doesn't matter, udev handles "allow-hotplug" interfaces just fine, I use it on several machines. But the last time I used the Etch installer was around May... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Roeckx escribió: > On Sun, Dec 17, 2006 at 06:07:18PM -0400, Jose Luis Rivas Contreras wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I'm maintaining libtorrent package, this source builds 2 binaries, >> libtorrent-rakshasa (is libtorrent9 last version in debian archive) and >> libtorrent-rakshasa-dev (is libtorrent9 last version in debian archive), >> I get this warning from lintian when I build the package. >> >> Now running lintian... >> W: libtorrent-rakshasa: package-name-doesnt-match-sonames libtorrent10 >> Finished running lintian. >> >> The version I'm building is libtorrent-0.11.0 so I don't think I should >> call the binary libtorrent10. > > Please check the real soname with objdump -p libtorrent-0.11.0 |grep > SONAME The real soname is libtorrent.so.10 So, should I name it libtorrent10? - -- ghostbar @ linux/debian 'unstable' on i686 - Linux Counter# 382503 http://ghostbar.ath.cx/ - irc.freenode.net #talug #velug #debian-es http://debianvenezuela.org.ve - irc.debian.org #debian-es #debian-ve CHASLUG -- http://chaslug.org.ve - irc.unplug.org.ve #chaslug San Cristobal - Venezuela. TALUG -- http://linuxtachira.org Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFhrBZOKCtW8rKsRgRAneOAJ94txj+uSnxu4NWWF+nB3+ZzHT4ZQCfQnM4 8WYy9Hb8+jyzwpbjzIo09qw= =zZr/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
On Mon, Dec 18, 2006 at 11:14:33AM -0400, Jose Luis Rivas Contreras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Sun, Dec 17, 2006 at 06:07:18PM -0400, Jose Luis Rivas Contreras wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> I'm maintaining libtorrent package, this source builds 2 binaries, > >> libtorrent-rakshasa (is libtorrent9 last version in debian archive) and > >> libtorrent-rakshasa-dev (is libtorrent9 last version in debian archive), > >> I get this warning from lintian when I build the package. > >> > >> Now running lintian... > >> W: libtorrent-rakshasa: package-name-doesnt-match-sonames libtorrent10 > >> Finished running lintian. > >> > >> The version I'm building is libtorrent-0.11.0 so I don't think I should > >> call the binary libtorrent10. > > > > Please check the real soname with objdump -p libtorrent-0.11.0 |grep > > SONAME > > The real soname is libtorrent.so.10 > > So, should I name it libtorrent10? Either the soname should be libtorrent.so.11, or you might want to rename libtorrent-0.11.0 to libtorrent-0.10.0 or something. If the soname really is and should be libtorrent.so.10, you want to name it libtorrent-rakshasa10 or something. But it should have the 10 in it. >From what I understand there are 2 incompatible libtorrent packages, so you want to reflect that in the name of the package. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need help with RC #396817
On Mon, 18 Dec 2006, John Goerzen wrote: 2) At least build and upload this package? Hi John: I have it building now. I'll let you know the outcome. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Roeckx escribió: > On Mon, Dec 18, 2006 at 11:14:33AM -0400, Jose Luis Rivas Contreras wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >>> On Sun, Dec 17, 2006 at 06:07:18PM -0400, Jose Luis Rivas Contreras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm maintaining libtorrent package, this source builds 2 binaries, libtorrent-rakshasa (is libtorrent9 last version in debian archive) and libtorrent-rakshasa-dev (is libtorrent9 last version in debian archive), I get this warning from lintian when I build the package. Now running lintian... W: libtorrent-rakshasa: package-name-doesnt-match-sonames libtorrent10 Finished running lintian. The version I'm building is libtorrent-0.11.0 so I don't think I should call the binary libtorrent10. >>> Please check the real soname with objdump -p libtorrent-0.11.0 |grep >>> SONAME >> The real soname is libtorrent.so.10 >> >> So, should I name it libtorrent10? > > Either the soname should be libtorrent.so.11, or you might > want to rename libtorrent-0.11.0 to libtorrent-0.10.0 or something. I can't that version already pass... > > If the soname really is and should be libtorrent.so.10, you want to name > it libtorrent-rakshasa10 or something. But it should have the 10 in it. Ok, so I'm renaming the package to libtorrent10-rakshasa and -dev. > >>From what I understand there are 2 incompatible libtorrent packages, so > you want to reflect that in the name of the package. > Yes, there's libtorrent-rasterbar (in a RFP, but I want to avoid problems in a near future), my packages were libtorrent9 and libtorrent9-dev, so I add to the name of the libraries "-rakshasa" to reflect that in the name. Thanks and Cheers!! - -- ghostbar @ linux/debian 'unstable' on i686 - Linux Counter# 382503 http://ghostbar.ath.cx/ - irc.freenode.net #talug #velug #debian-es http://debianvenezuela.org.ve - irc.debian.org #debian-es #debian-ve CHASLUG -- http://chaslug.org.ve - irc.unplug.org.ve #chaslug San Cristobal - Venezuela. TALUG -- http://linuxtachira.org Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFhr0pOKCtW8rKsRgRAr5zAJ4qLKHfOrr9fe3C2lcJpU4F62KkTgCg0eMF UGHUzA0TBliBAp4kbZTrj+0= =ZJAe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ÅÞÈÖ ßÜÇÔ ãÜä íæÑíÜßÜÇ
Title: Eureka
Re: Name of a binary package according to sonames
On Mon, Dec 18, 2006 at 12:09:13PM -0400, Jose Luis Rivas Contreras wrote: > > The version I'm building is libtorrent-0.11.0 so I don't think I should > call the binary libtorrent10. > >>> Please check the real soname with objdump -p libtorrent-0.11.0 |grep > >>> SONAME > >> The real soname is libtorrent.so.10 > >> > >> So, should I name it libtorrent10? > > > > Either the soname should be libtorrent.so.11, or you might > > want to rename libtorrent-0.11.0 to libtorrent-0.10.0 or something. > > I can't that version already pass... If the soname is set to libtorrent.so.10, it means applications will start to look for a file called "/usr/lib/libtorrent.so.10". That will probably be a symlink in your case to libtorrent-0.11.0, which looks rather confusing to me. In libtorrent9 you have a file called "/usr/lib/libtorrent.so.9". But there doesn't seem to be a file named libtorrent-0.9.0.so or something, so I'm a little confused what changed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Roeckx escribió: > On Mon, Dec 18, 2006 at 12:09:13PM -0400, Jose Luis Rivas Contreras wrote: >> The version I'm building is libtorrent-0.11.0 so I don't think I should >> call the binary libtorrent10. > Please check the real soname with objdump -p libtorrent-0.11.0 |grep > SONAME The real soname is libtorrent.so.10 So, should I name it libtorrent10? >>> Either the soname should be libtorrent.so.11, or you might >>> want to rename libtorrent-0.11.0 to libtorrent-0.10.0 or something. >> I can't that version already pass... > > If the soname is set to libtorrent.so.10, it means applications will > start to look for a file called "/usr/lib/libtorrent.so.10". That will > probably be a symlink in your case to libtorrent-0.11.0, which looks > rather confusing to me. > > In libtorrent9 you have a file called "/usr/lib/libtorrent.so.9". But > there doesn't seem to be a file named libtorrent-0.9.0.so or something, > so I'm a little confused what changed. No, there's only libtorrent.so.10 libtorrent.so.10.0.0 in my build (libtorrent-0.11.0) I'm more confused since I renamed the package to libtorrent10-rakshasa and libtorrent-rakshasa10 and lintian keeps giving me the warning... Jose - -- ghostbar @ linux/debian 'unstable' on i686 - Linux Counter# 382503 http://ghostbar.ath.cx/ - irc.freenode.net #talug #velug #debian-es http://debianvenezuela.org.ve - irc.debian.org #debian-es #debian-ve CHASLUG -- http://chaslug.org.ve - irc.unplug.org.ve #chaslug San Cristobal - Venezuela. TALUG -- http://linuxtachira.org Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFhsdYOKCtW8rKsRgRAg2iAKCqVE6x7lYUQoSKGvBsUrA4q4kdwgCfVRZ/ SRiDJbmdP0TU7pDbvE1Tbkc= =oOay -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need help with RC #396817
On Mon, Dec 18, 2006 at 10:55:48AM -0600, Carlo Segre wrote: > On Mon, 18 Dec 2006, John Goerzen wrote: > > >Hi, > > > >#396817 was reported back in November. Ian Lynagh, maintainer of GHC, > >and I both believe that the build was proceeding normally and that on > >the platform in question, it is not unreasonable to expect it to > >take quite a bit of time to compile that file. > > > > OK, it builds. WOuld you like me just to upload? Yes, please, and thanks for your help! -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need help with RC #396817
On Mon, 18 Dec 2006, John Goerzen wrote: Hi, #396817 was reported back in November. Ian Lynagh, maintainer of GHC, and I both believe that the build was proceeding normally and that on the platform in question, it is not unreasonable to expect it to take quite a bit of time to compile that file. OK, it builds. WOuld you like me just to upload? Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED] http://www.iit.edu/~segre [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402622: bug still not fixed
Le samedi 16 décembre 2006 à 00:16 +0100, Marco d'Itri a écrit : > On Dec 14, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > > > Let's say it this way: which devices that use the MMC protocol (or SD > > storage) > > are non-removable? > Nevermind, I tought that the MTD drivers shared the same infrastructure. > I will upload a new udev package forcing all mmc, firewire, usb and > pcmcia block devices to be owned by the floppy group (as usual, patches > are welcome). Does this mean the plugdev group is going away? -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#403584: RFH: apt-cacher -- caching proxy system for Debian package and source files
[There is a X-debbugs-cc header which allows easier handling of bug mail gated to the lists] On Monday 18 December 2006 10:16, Eduard Bloch wrote: > And/Or help developing or rewritting the incomplete designated > successor, apt-cacher-ng (currently C++ with some sugar). Not to dissuade anyone from yet another interesting project (I have my own share of reinvent-the-wheel projects), but I think yet another new apt cache project needs some justification. What are the downsides of approx and apt-proxy that merit the effort of rewriting apt-cacher? (I assume the current apt-proxy codebase is not up to your standards if a rewrite has been found necessary.) cheers -- vbi -- Some of you may have heard of this crazy company called SCO (aka "Smoking Crack Organization") who seem to have a hard time believing that open source works better than their five engineers do. -- Linus Torvalds pgpyt5areXB6O.pgp Description: PGP signature
Re: Name of a binary package according to sonames
Jose Luis Rivas Contreras wrote: > I'm more confused since I renamed the package to libtorrent10-rakshasa > and libtorrent-rakshasa10 and lintian keeps giving me the warning... I am giving a try at the rasterbar's library, and ran into the same issue. I asked on #debian-mentors and they told me that a lintian override was needed in that case. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible grave bug in debian-installer or ifupdown?
* Gabor Gombas: > On Mon, Dec 18, 2006 at 09:23:13AM +0100, Bastian Venthur wrote: > >> But who has created the allow-hotplug-line? I thought hotplug is dead? > > Doesn't matter, udev handles "allow-hotplug" interfaces just fine, I use > it on several machines. I've seen it quite a few times that udev fails to bring up allow-hotplug interfaces. But I haven't figured out how to reproduce it, probably it's some kind of race condition in the boot process. I'd definitely recommend to use "auto" instead of "allow-hotplug" for the primary network interface in etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need help with RC #396817
On Mon, 18 Dec 2006, John Goerzen wrote: On Mon, Dec 18, 2006 at 10:55:48AM -0600, Carlo Segre wrote: On Mon, 18 Dec 2006, John Goerzen wrote: Hi, #396817 was reported back in November. Ian Lynagh, maintainer of GHC, and I both believe that the build was proceeding normally and that on the platform in question, it is not unreasonable to expect it to take quite a bit of time to compile that file. OK, it builds. WOuld you like me just to upload? Yes, please, and thanks for your help! Done, I simply built it so you will have to close the bug by hand. It took some time to build by pbuilder but it was certainly not 90 minutes. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED] http://www.iit.edu/~segre [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
On Mon, Dec 18, 2006 at 12:52:40PM -0400, Jose Luis Rivas Contreras wrote: > > If the soname is set to libtorrent.so.10, it means applications will > > start to look for a file called "/usr/lib/libtorrent.so.10". That will > > probably be a symlink in your case to libtorrent-0.11.0, which looks > > rather confusing to me. > > > > In libtorrent9 you have a file called "/usr/lib/libtorrent.so.9". But > > there doesn't seem to be a file named libtorrent-0.9.0.so or something, > > so I'm a little confused what changed. > > No, there's only libtorrent.so.10 libtorrent.so.10.0.0 in my build > (libtorrent-0.11.0) So, your source package is "libtorrent" version is 0.11.0, which has a binary package libtorrent10-rakshasa with a library called libtorrent.so.10, and also has that soname. That all looks good. > I'm more confused since I renamed the package to libtorrent10-rakshasa > and libtorrent-rakshasa10 and lintian keeps giving me the warning... I think in this case you can probably ignore the warning. Do you conflict with the -dev package of the other libtorrent package? You'll both want to have a /usr/lib/libtorrent.so, so you should conflict. You probably now don't have a conflict with other library package now, but at some point this might happen. And I think this should be avoided. I think either one or both should really change the name of the library itself, to avoid all confusion, and also make them not conflict. For instance, you could name it librakshasatorrent (or librtorrent). The ideal solution would be that there really was only 1 libtorrent package, and that both current of them worked on 1 library. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils [was: Re: Upgrading the priority of ucf]
On Mon, Dec 18, 2006 at 02:01:11PM +, Tim Cutts wrote: > I still use it on some real-world servers, but I can't now remember > why. I definitely found something which only worked with the > userland server. uid mapping, perhaps? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#403506: ITP: fdisk -- linux fdisk replacement based on libparted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/18/06 03:58, Luca Capello wrote: > Hello! > > On Mon, 18 Dec 2006 09:50:10 +0100, Michael Banck wrote: >> On Sun, Dec 17, 2006 at 10:58:29PM +0100, Julien Louis wrote: >>> I'll rename the package to gnu-fdisk reflect binary name changes. >> The usual naming scheme seems to be to prepend the name with a `g', >> see glibc, gcc, gawk, etc. > > I think the main problem here is that the GNU fdisk page [1] already > refers to another gfdisk, which AFAIK should be the GNOME fdisk, > lately renamed to gnome-fdisk [2]. The namespace confusion is enough to make you want to use OSX... Well, not really, but it sure gets confusing! > Thx, bye, > Gismo / Luca > > Footnotes: > [1] http://www.gnu.org/software/fdisk/ > [2] http://live.gnome.org/ListOfCVSModulesArchive - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFhxToS9HxQb37XmcRAnHLAJ9xMyt6/+mL2bdLLYCfN67rMpwOiQCfYJHW f6xXPz6Z9fyNAY9kPju00l0= =ddYG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug is very vague, should I close it?
Jose Luis Rivas Contreras <[EMAIL PROTECTED]> writes: > Ben Finney escribió: > > Jose Luis Rivas Contreras <[EMAIL PROTECTED]> writes: > [...] > >> > >> So, should I close this bug? There's a lot of bugs requesting > >> specific features[1] so I don't think this bug it's necessary. > > > > You could enlist the bug submitter's help. Ask them to retitle the > > bug and be more specific about a particular feature, or to close > > it and submit separate wishlist bugs for each feature they want. > > > So I will close the bug since all the features are already requested > in another wishlist bugs. That's the opposite of what I was suggesting. It's your privilege (as the package maintainer) to do so if you wish, of course. -- \"There was a point to this story, but it has temporarily | `\ escaped the chronicler's mind." -- Douglas Adams | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is bug #399214 release critical? (Upgrade from version not in debian currently)
Daniel J. Priem wrote: > > I think such bugs can be easily closed. The bug is closed with the last upload to sid, the question is whether it should be considered as RC and if the release team will approve the fix for Etch. When upgrading from Sarge to Etch there is no issue, but for users like me (that particular machine is running testing) it is a real PITA. I intend to upgrade and remain on Etch (stable) when it is released, so I'll have a broken package. There's no way to remove/purge or upgrade it (well, there is, but it would be difficult for the average user). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible grave bug in debian-installer or ifupdown?
On 12/18/06 08:18:54PM +0100, Florian Weimer wrote: > * Gabor Gombas: > > > On Mon, Dec 18, 2006 at 09:23:13AM +0100, Bastian Venthur wrote: > > > >> But who has created the allow-hotplug-line? I thought hotplug is dead? > > > > Doesn't matter, udev handles "allow-hotplug" interfaces just fine, I use > > it on several machines. > > I've seen it quite a few times that udev fails to bring up > allow-hotplug interfaces. But I haven't figured out how to reproduce > it, probably it's some kind of race condition in the boot process. > > I'd definitely recommend to use "auto" instead of "allow-hotplug" for > the primary network interface in etch. > I would agree, when I did an install of etch a few weeks ago the use of allow-hotplug caused the network to come up later in the boot process and caused problems with syslog-ng remote logging. Apparently when syslog-ng can't connect to one of it's destinations on startup it fails completely, this is probably a bug in syslog-ng but it's definitely been exacerbated by the default ifupdown configuration in etch. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Advice: managing inetd entries for cvs
Hi, I've got a serious bug (#403334) open against cvs over the way it handles some of its configuration via debconf, specifically its inetd configuration for the pserver. At the moment, the package will reconfigure inetd on each upgrade, which is quite clearly a bug. If the local admin has changed the pserver inetd entry by hand since the package was installed, then those changes will be lost ---> bug. Most network daemons fall into one of two camps: 1) installation implies an inetd entry, no configuration is expected (e.g. tftpd) 2) there's a choice of running from inetd or standalone (e.g. proftpd) cvs, however, is commonly configured both ways, either with an inetd entry (for remote pserver access) and without (as a client only, or remote access via ssh). This seems to be quite a rare setup. There are more complications, though: 1) cvs *also* optionally changes the inetd respawn limit, as heavy pserver usage will otherwise quickly trigger the inetd respawn protection. 2) update-inetd allows for easy *changing* of inetd entries in a server-independent manner (e.g. for old-style inetd and in theory for xinetd too), but there is no equivalent method for *reading* the current inetd config in a portable fashion. 3) update-inetd will ignore lines starting with a single "#", as configured by the admin. Enabling/re-enabling the pserver using update-inetd may fail in these situations. Given these issues, there doesn't seem to be a safe way at all for cvs to automatically configure itself via inetd. Peter suggested grepping the inetd.conf file to read current config, but I'm not convinced that's such a good idea due to its lack of portability. I'm beginning to think that the best way to go might be to just ignore inetd setup altogether from the package config point of view, or at best simply add an inetd entry *once* at initial installation time if the user asks for it then add a section in README.Debian to tell the user what needs doing. Thoughts/suggestions welcome! Have I missed anything screamingly obvious here? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "Because heaters aren't purple!" -- Catherine Pitt signature.asc Description: Digital signature
Re: =?ISO-8859-1?Q?=C7=CD=E1=EC =E6 =C7=CC=E3=E1 =CA=CC=E3=DA =C8=E4=C7=CA ?= æ ÔÈÇÇÈ ÇáÎáíÌ
ÍíÇßã æíÇäÇ ÈÇÍáì æ ÇÌãá ÊÌãÚ ááÈäÇÊ æ ÇáÔÈÇÈ æ ÔÇÊ ÝÑíÏ ãä äæææÚå ãÏãæÌ ÈÇáãäÊÏì Ííßã http://www.al-rayyan.org/forums -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Roeckx escribió: > On Mon, Dec 18, 2006 at 12:52:40PM -0400, Jose Luis Rivas Contreras wrote: >>> If the soname is set to libtorrent.so.10, it means applications will >>> start to look for a file called "/usr/lib/libtorrent.so.10". That will >>> probably be a symlink in your case to libtorrent-0.11.0, which looks >>> rather confusing to me. >>> >>> In libtorrent9 you have a file called "/usr/lib/libtorrent.so.9". But >>> there doesn't seem to be a file named libtorrent-0.9.0.so or something, >>> so I'm a little confused what changed. >> No, there's only libtorrent.so.10 libtorrent.so.10.0.0 in my build >> (libtorrent-0.11.0) > > So, your source package is "libtorrent" version is 0.11.0, which has a > binary package libtorrent10-rakshasa with a library called > libtorrent.so.10, and also has that soname. Yes > > That all looks good. > >> I'm more confused since I renamed the package to libtorrent10-rakshasa >> and libtorrent-rakshasa10 and lintian keeps giving me the warning... > > I think in this case you can probably ignore the warning. > > Do you conflict with the -dev package of the other libtorrent package? > You'll both want to have a /usr/lib/libtorrent.so, so you should > conflict. - -dev is used just for building rtorrent and -dev needs libtorrent-rakshasa so if I conflict them -dev can't build. > > You probably now don't have a conflict with other library package now, > but at some point this might happen. And I think this should be > avoided. > > I think either one or both should really change the name of the library > itself, to avoid all confusion, and also make them not conflict. For > instance, you could name it librakshasatorrent (or librtorrent). Well, the one with rasterbar will name it libtorrent-rasterbar and I will name the library libtorrent-rakshasa, so, I think there's no conflict. > > The ideal solution would be that there really was only 1 libtorrent > package, and that both current of them worked on 1 library. Well, rakshasa is used by rtorrent, and rasterbar is used by another bittorrent clients. > > > Kurt > > Thanks!! Jose - -- ghostbar @ linux/debian 'unstable' on i686 - Linux Counter# 382503 http://ghostbar.ath.cx/ - irc.freenode.net #talug #velug #debian-es http://debianvenezuela.org.ve - irc.debian.org #debian-es #debian-ve CHASLUG -- http://chaslug.org.ve - irc.unplug.org.ve #chaslug San Cristobal - Venezuela. TALUG -- http://linuxtachira.org Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFh1C2OKCtW8rKsRgRAkYVAJ4rDfVvgxvmuaJ6ueZ12nj2KtRHIACg0l+l dEBZkTiLNTrVxh5fJ6ywrZ4= =eh+/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Felipe Sateler escribió: > Jose Luis Rivas Contreras wrote: > >> I'm more confused since I renamed the package to libtorrent10-rakshasa >> and libtorrent-rakshasa10 and lintian keeps giving me the warning... > > I am giving a try at the rasterbar's library, and ran into the same issue. I > asked on #debian-mentors and they told me that a lintian override was > needed in that case. > Yes, that's what I will do, that's the only solution. :/ Thanks!! Jose - -- ghostbar @ linux/debian 'unstable' on i686 - Linux Counter# 382503 http://ghostbar.ath.cx/ - irc.freenode.net #talug #velug #debian-es http://debianvenezuela.org.ve - irc.debian.org #debian-es #debian-ve CHASLUG -- http://chaslug.org.ve - irc.unplug.org.ve #chaslug San Cristobal - Venezuela. TALUG -- http://linuxtachira.org Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFh1DsOKCtW8rKsRgRAhc2AKCDCWD4D6e10hakmlcMIZKjwP9J8ACgluAq n0s71KCyvGLfYb8BSlEmFcY= =cUuJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403704: ITP: serf -- High-performance asynchronous HTTP client library
Package: wnpp Severity: wishlist Owner: Noritada Kobayashi <[EMAIL PROTECTED]> * Package name: serf Version : 0.1.0 Upstream Author : The Apache Software Foundation (http://www.apache.org/) * URL : http://code.google.com/p/serf/ * License : Apache License 2.0 Description : High-performance asynchronous HTTP client library serf library is a C-based HTTP client library built upon the Apache Portable Runtime (APR) library. It multiplexes connections, running the read/write communication asynchronously. Memory copies and transformations are kept to a minimum to provide high performance operation. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-686 Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
