lists.debian.org
Hi all, can one tell me which mailinglist manager is used at lists.debian.org? (mailman/sympa)? Thanks is advance Elimar -- Obviously the human brain works like a computer. Since there are no stupid computers humans can't be stupid. There are just a few running with Windows or even CE ;-)
alioth down?
Hi all, what is the reason why alioth.debian.org can't be reached? A traceroute for git.debian.org stops at bm-bl1.debian.org (5.153.231.241). Thanks Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-)
Re: Intel Skylake/Kaby Lake Hyper-threading bug update
Hi Henrique, * Henrique de Moraes Holschuh [2017-07-23 14:56 -0300]: > TL;DR: Intel has issued public microcode updates in 2017-07-07, fixing > the hyper-threading errata on every affected processor. These updates > have been included in the stable and oldstable point releases from > 2017-07-22. > > The microcode updates in the "intel-microcode" packages with the base > version of 3.20170707.1 fix the hyper-threading defect on every known- > affected Intel processor, including Kaby Lake and all variants of > Skylake. > > Updated intel-microcode packages are already available for oldstable, > stable, testing, unstable, jessie-backports-sloppy and > stretch-backports. many, many thanks. You did a famous job! Elimar -- The path to source is always uphill! -unknown-
Re: Request for feedback: systemd backport for jessie
Hi Mika, * Michael Prokop [2016-07-05 17:34 +0200]: > Hi, > > here at DebConf I've been working on a backport of systemd for jessie. > > If you're interested in all the new features, bugfixes and changes > that systemd received since its version 215-17+deb8u4 (the one > available from jessie) you might wanna give it a try. > > The backport is based on what will be released as v230-6 for Debian > unstable soonish. Once systemd v230-6 migrated to testing and if I > receive enough feedback I'll upload systemd v230-6 officially > towards jessie-backports then. Are you aware of the 'Thinking about a "jessie and a half" release' thread at debian-devel [0]? [0] https://lists.debian.org/debian-devel/2016/07/msg00054.html Elimar -- From The Collaborative International Dictionary of English v.0.48 [gcide]: . arsehole \arse"hole`\ ([aum]rs"h[=o]l`), n. 1. execretory opening at the end of the alimentary canal. -- randomly choosed!
Re: Neomutt packages available
* Jonathan Dowland [2016-06-24 09:24 +0100]: > On Thu, Jun 23, 2016 at 09:10:50PM +0200, Elimar Riesebieter wrote: > > I am pleased to announce the availability of neomutt [0] packages for > > Debian. Hints for installation you'll find at [1]. > snip > > > > I've packaged neomutt for Debian. A Debian ITP [2] is filed. > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825821 > > For those on -devel not up to speed on what is going on (such as me) the > ITP makes interesting reading. > > The existing mutt maintainers have a considered plan to move to neomutt > for the existing mutt packages (at least mutt-patched and quite likely > mutt itself). This I am not aware of. I never noticed such a consideration. AFAIK mutt maintainers are in contact to neomutt upstream, but thats it. > Rather than work with the existing team Elimar has persisted with > efforts to package neomutt separately and has even suggested a *different* > team is set up to maintain neomutt, versus pkg-mutt. From my point of view we need the "legacy mutt" in Debian as well as the neomutt. My package replaces mutt and therefor mutt-patched and mutt-kz as well. To join the Debian distro there should be a replace of neomutt in the mutt-package. At the moment Debian neomutt uses mutt as the binary name. > A fork by any other name smells just as sweet. Well, neomutt isn't a fork really. It is an incredible complement of mutt gathered by Richard Russon! Elimar -- .~. /V\ L I N U X /( )\ >Phear the Penguin< ^^-^^
Neomutt packages available
Hi all, I am pleased to announce the availability of neomutt [0] packages for Debian. Hints for installation you'll find at [1]. I've packaged neomutt for Debian. A Debian ITP [2] is filed. The binaries are build in a sid environment. The sources are fetched from [3]. The neomutt branch is used. I'll update packages as needed. Please test the packages and let me know of any further glitches you find. If you want, you can open an issue on [3]. The Debian Bug Tracking System is not involved as the package isn't uploaded yet, but will be soon. Thanks in advance for your cooperation Elimar [0] http://www.neomutt.org/ [1] http://www.lxtec.de/debarchiv [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825821 [3] https://github.com/neomutt/neomutt -- The path to source is always uphill! -unknown-
Re: Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.
* Faidon Liambotis [2016-05-30 20:56 +0300]: > On Mon, May 30, 2016 at 06:42:21PM +0200, Elimar Riesebieter wrote: > > I've contacted Antonio Radici, Christoph Berg, "Matteo F. Vescovi" and > > Faidon Liambotis via PM a while ago. > > I'll respond here, unfortunately without not much context, as that was a > PM and I wouldn't want to forward without permission. All is said in this thread. Nothing mysterious ;-) > So, first of, a bit of a background for the ITP: > > - The mutt maintainers have been engaging with the neomutt upstream > already. I, in fact, joined the mutt maintainer group precisely for > this purpose. See https://github.com/neomutt/neomutt/issues/23 and > others. Well, I've noticed that you prepared mutt-1.6.1 which resides in experimental. I suppose you had to rework the neomutt patches so that they apply? The neomutt part is foreseen as a patch bomb to mutt-patched which is IMHO a bad idea and will increase the gap to mutt a lot. And this is the point where a neomutt package should jump in ;-) > - Debian is already shipping neomutt partially already; mutt 1.6.1-1 > already replaces some of our home-grown patches with neomutt's. See above. You will always maintain patches and not an upstream source. > - Debian has *not* been shipping a vanilla mutt for years. Debian has > been shipping mutt, mutt-patched and mutt-kz, the former two from > src:mutt and the latter from src:mutt-kz. All of them, including the > binary package called "mutt" are heavily patched, to a large extent > with patches that neomutt ships (ifdef, compressed folders, > trash/purge) but a lot of others as well. The patches Debian provides for the mutt package (not mutt-patched!) carry mutt to a more modern mutt package and should just remain! > - The neomutt upstream (Cc'ed) has been incredibly responsive and > receptive to requests, both in general and to Debian's needs > specifically. Besides us, he's been bringing together many other > downstreams (distros and BSDs). Richard did a famous work and released a neomutt-distro patch package, where beside others all Debian specific patches are included and made applicable. A big thank you for him ;-) > - Considering the above, consensus between the mutt maintainers so far > (and AIUI) has been that the mutt source package should switch > upstreams and start tracking neomutt. This would basically mean having > *one* source and *one* binary package for mutt in Debian (not counting > transitional packages). You will have a mutt including a patch bomb. > - This has been waiting to some extent on the new neomutt release which > includes compressed folders and NNTP, released just today. > > As such, I think this ITP is superfluous, at least for now. Even if it > is not, pkg-mutt should own this ITP, not Elimar alone -- as we are > already the de facto downstreams of neomutt in Debian. I intend to package neomutt which is an intrinsically package which has a cooperative upstream. If we have a separated neomutt package it should be easy to maintain and one doesn't have to fight with fuzzes and offsets. It can't be the intention of Debian to patch a GPL'd upstream to a totally over patched monster. I would be happy about every co-maintainer as I am thinking about a git repo at alioth maintained by the "neomutt-package-maintainers", yay. > We could certainly revisit the decision to ship two source packages in > Debian, src:mutt and src:neomutt (the eventual deprecation of > mutt-patched and src:mutt-kz is widely agreed at this point, I think). > I still haven't heard a convincing response of what would happen to the > "mutt" binary package, though. As I explained above, we're not shipping > a vanilla mutt and haven't been doing so for many years now. Switching > back to the vanilla mutt would be a regression at this point and break > user expectations on upgrades. Keeping the status quo, on the other > hand, would mean just a huge waste of effort for maintaining and > forward-porting patches that neomutt upstream is already doing a better > job at. From my point of view the mutt package should remain as it is. There will be much users who don't want to use mutt-patched or neomutt. The sidebar, notmuch and nntp features for instance aren't that popular for legacy, let say conservative, users. There will be always a chance to choose between a mutt (with some incorporated patches) and a neomutt package. And with a neomutt package in Debian we will honour the work of its upstream! > > I also haven't heard a convincing response on what would happen > with all of the patches shipped in src:mutt's debian/patches that > are not in neomutt yet; effectively
Re: Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.
* Evgeni Golov [2016-05-30 21:11 +0200]: > Hi, > > > > On Mon, 2016-05-30 at 13:00 +0200, Elimar Riesebieter wrote: > > > > * Package name: neomutt > > Please don't. We don't need another mutt fork in Debian. Its not a fork. It's just an additional packege like in real life: mutt and neomutt Elimar -- The path to source is always uphill! -unknown- signature.asc Description: PGP signature
Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.
Package: wnpp Severity: wishlist Owner: Elimar Riesebieter * Package name: neomutt Version : 20160502 Upstream Author : Richard Russon * URL : https://www.neomutt.org/ * License : GPL-2 Programming Lang: C Description : text-based mailreader which gathers all the patches against Mutt. . NeoMutt is a sophisticated text-based Mail User Agent supporting MIME, GPG, PGP and threading. . NeoMutt was created when Richard Russon (FlatCap) took all the old Mutt patches, sorted through them, fixed them up and documented them. . It's not a fork of Mutt. It's a large set of feature patches (big and small) that apply to Mutt. . A list of additional features on top of pristine mutt: Compressed FoldersRead from/write to compressed mailboxes Conditional Dates Conditional Date Formatting Fmemopen Use fmemopen(3) for speedier temporary files Ifdef Conditional config options Index Color Theming of the Index List Initials Expando Expando for Author's Initials Keywords Labels/Tagging for emails Limit-Current-Thread Limit Index View to Current Thread Nested If Allow deeply nested conditionals in format strings NNTP Talk to a Usenet news server Notmuch Powerful email search engine Progress Bar Colourful Progress Bar Quasi-Delete Hide emails from view, but don't delete them Sensible-Browser Highlight the folder you *used* to be in Sidebar Panel containing list of Mailboxes Skip-Quoted Skip Quoted Text Status Color Theming of the Status Bar TLS-SNI Negotiate with a Server for a Certificate Trash Folder Move 'deleted' emails to a trash folder Richard prepares a new Release (20160530?) which will incoperate Debian specific patches in seperated branch. 20160502 and probably 20160530 are will apply against mutt-1.6.1. Thanks -- Elimar
Re: bat: 3 different programms and one name
* Guus Sliepen [2016-02-03 20:23 +0100]: > On Wed, Feb 03, 2016 at 07:54:22PM +0100, Elimar Riesebieter wrote: > > > It seems that we have /usr/bin/bat and /usr/share/man/man1/bat.1.gz > > three times in unstable: > > > > bacula-console-qt > > bareos-bat > > alsa-utils > > > > It should be easy to rename ie alsa's bat to bat-alsa but should > > this be mentioned in a patched manpage as well? > > > > How is the correct way to solve this? > > The correct way is indeed to rename the binary. Another suggestion is to > name it "basic-audio-tester" instead of "bat-alsa". Inform upstream of > their conflict with existing programs with the same name, so perhaps > they can change it as well. Upstream cooperated and provided a patch with new names. Please note that the upload of alsa-utils/1.1.0-2 doesn't fix the name conflict in bacula-console-qt and bareos-bat! Thanks Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche
bat: 3 different programms and one name
Hi all, after uploading alsa-utils 1.1.0-1 #813473 popped up [0]. It seems that we have /usr/bin/bat and /usr/share/man/man1/bat.1.gz three times in unstable: bacula-console-qt bareos-bat alsa-utils It should be easy to rename ie alsa's bat to bat-alsa but should this be mentioned in a patched manpage as well? How is the correct way to solve this? [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813473 Any hint is appreciated. Thanks in advance -- Do you smell something burning or is it me?
Re: libpopt
* Paul Wise [05 19:00 +0800]: [...] > For Debian there are only disadvantages to inlined popt in most cases. Thanks for all your advises. I'll take care of them by packaging a new version of moc build against libpopt-dev. Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2005114538.gd3...@samweis.home.lxtec.de
libpopt
Hi all, we have many packages which are build against popt. Some of them have included a bundled (inlined) verion of popt. But they are using Debian's libopt-dev like pkg-config. Can someone please advise me on how to handle this. I don't find a section in Debian's Policy which describes how to handle inlined libs, which exist as a sepearte package as well. Does one know why some upstream developers are packaging popt inside? Are there any advantages to use inlined popt over libpopt-dev? Thanks for any suggestions Elimar -- Experience is something you don't get until just after you need it! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2005104527.ga3...@samweis.home.lxtec.de
Re: Bug#645656: network-manager in Gnome
* Josselin Mouette [03 18:53 +0100]: > Le jeudi 03 novembre 2011 à 15:26 +0100, Elimar Riesebieter a écrit : > > Hmm, does NM works if nis runs ? nis daemon has by default no > > time-out, starts before NM provides a network and locks the machine > > lng time 'til root can become access to stop nis. > > You don???t use NIS on a desktop machine without a local cache, so this is > a non-issue. I know many networks in production use which rely on NIS without a local cache (whatever this means). NM should be a recommends only to gnome-core. You want to decide by yourself how to connect to a network, so "Depends: ... gnome-network-manager" is a no-go. Elimar -- Obviously the human brain works like a computer. Since there are no stupid computers humans can't be stupid. There are just a few running with Windows or even CE ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2004102607.ga3...@samweis.home.lxtec.de
Re: Bug#645656: network-manager in Gnome
* Laurent Bigonville [01 14:14 +0100]:
> Le Tue, 1 Nov 2011 12:31:26 +,
> Ian Jackson a écrit :
>
> > Josselin Mouette writes ("Bug#645656: network-manager in Gnome"):
> > > Le lundi 31 octobre 2011 à 16:37 +, Ian Jackson a écrit :
> > > > I agree with the original submitter of this bug that
> > > > network-manager needs to be optional. In particular, gnome-core
> > > > should not pull it in. What can be done in Debian's gnome-core
> > > > to fix this ?
> > >
> > > There?s nothing to fix. NM is now part of the official moduleset
> > > for the core GNOME desktop.
> >
> > I would like to ask you to reconsider this approach. network-manager
> > is not acceptable to many Debian users, and those users should be able
> > to use Gnome. In particular, I would like to know what will go wrong
> > if network-manager is removed and what can be done to mitigate that.
> >
> > Saying that "this is now officially part of Gnome" is no answer at
> > all. Just because Gnome upstream do something doesn't mean we have to
> > do it too.
>
> Well as already said, gnome-core meta-package depends on official core
> GNOME modules, which network-manager is part of. If you don't want to
> install network-manager, don't install gnome-core meta-package.
Hmm, does NM works if nis runs ? nis daemon has by default no
time-out, starts before NM provides a network and locks the machine
lng time 'til root can become access to stop nis.
Elimar
--
.~.
/V\ L I N U X
/( )\ >Phear the Penguin<
^^-^^
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2003142635.ga4...@samweis.home.lxtec.de
Bug#516585: RFH: alsa-lib
Package: wnpp Severity: normal Hi Debian ALSA developers, I want to prepare alsa-lib 1.0.19 for upload. Building alsa-lib on i386 and amd64 gives: ... checking for strip... strip checking for cross-compiler... i486-i486-pc-linux-gnu-gcc checking for i486-linux-gnu-gcc... i486-i486-pc-linux-gnu-gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [configure-biarch-stamp] Error 77 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 debuild: fatal error at line 1319: dpkg-buildpackage -rfakeroot -D -us -uc failed Command /bin/sh -c debuild "-rfakeroot" failed in , how to continue now? [Qri?]: q Aborting. The correct compiler should be: i486-linux-gnu-gcc and not i486-i486-pc-linux-gnu-gcc! From upstreams changelog: "Don't use AC_CANONICAL_SYSTEM, only use AC_CANONICAL_HOST" Hmmm. Building on ppc runs fine. Others I can't test. You can co the version I tried from svn (r 2165): svn://svn.debian.org/pkg-alsa/trunk/alsa-lib http://svn.debian.org/wsvn/pkg-alsa/trunk/alsa-lib/ The orig tgz must be loaded from: wget ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.0.19.tar.bz2 tar jxf alsa-lib-1.0.19.tar.bz2 tar zcf alsa-lib-1.0.19.tar.gz alsa-lib-1.0.19 mv alsa-lib-1.0.19.tar.gz alsa-lib_1.0.19.orig.tar.gz Any hints? Thanks for cooperation Elimar -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) -- Learned men are the cisterns of knowledge, not the fountainheads ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ries.debian.org AKA ftp-master.debian.org back
On Mon, 12 Nov 2007 the mental interface of Joerg Jaspert told: > Hi > > following my last mail on this topic[1] I now have good news for you: > ries.debian.org AKA ftp-master.debian.org AKA "the main copy of the > archive" AKA (lots of) "OH GOD, i can't live without uploading > packages/getting updates" is back up. :) $ lynx http://incoming.debian.org shows an awfully bad formated directory listing and the dak files as well. Is that usual now? Elimar -- Experience is something you don't get until just after you need it! signature.asc Description: Digital signature
Re: Rfh: test mdadm 2.6.3-1
On Sat, 22 Sep 2007 the mental interface of martin f krafft told: > Dear list, > > I am ready to upload mdadm 2.6.3-1, but when I installed it on my > home machine just before I left to Ireland, it failed to boot. I am > almost sure that this was due to #441211, but I can't be sure. > Unfortunately, I also had to remove my vmware setup from the laptop > due to lack of space, so I have no testing environment. > > If any of you are in the position to test mdadm 2.6.3-1, please do > and report back. Does it boot systems with root on RAID? Does it > boot other RAID systems? Does it affect systems without RAID? mdadm - v2.6.3 - 20th August 2007 Booting form an array: RAID1: /dev/md3 /boot /dev/md6 / /dev/md7 /usr /dev/md8 /usr/local /dev/md9 /var Seems to be ok here ;) Elimar -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443222: ITP: uriparser -- URI parsing library compliant with RFC 3986
On Wed, 19 Sep 2007 the mental interface of Adeodato Simó told: [...] > uriparser has the following features: > . > * strictly compliant to RFC 3986, implementing: > + parsing > + reference resolution > + recomposition > + syntax-based normalization > * fast (linear input length time complexity) > * unicode support It looks like it can be used to strip uri's out of MUA to view i.e. inet pages similar to urlview? Elimar -- Excellent day for drinking heavily. Spike the office water cooler;-)
Re: X-Virus-Scanned: at lists.debian.org with p-bank en-ht
On Sun, 09 Sep 2007 the mental interface of Martin Zobel-Helas told: [...] > p-bank means policy bank. that can also be found in the debian package. In which one? > en-ht means "english, high traffic". That helps us for setting per list > policies in the spamfilter. We grouped together several debian mailing > lists. All of group en-ht should now have the same settings in SA and > amavis. Sounds reasonable ;) But should be announced to ldo subsribers? > > All mails I receive coming from lists.debian.org do have this > > header. > > Yes, and this will stay this way. OK > Greetings > Martin, having a hat on, guess which. A red one? Elimar -- >what IMHO then? IMHO - Inhalation of a Multi-leafed Herbal Opiate ;) --posting from alex in debian-user-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
X-Virus-Scanned: at lists.debian.org with p-bank en-ht
Hi all, since today I noticed the above mail header. Could one enlight me what p-bank is? I can't find something similar in the pkg databse. All mails I receive coming from lists.debian.org do have this header. Elimar -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#433119: nfs-common: NFS volume no longer mounted on boot
On Sat, 14 Jul 2007 the mental interface of Steinar H. Gunderson told: > On Sat, Jul 14, 2007 at 06:17:13PM +0200, Frans Pop wrote: > > I'm not all that interested in what the right long-term fix is, I'm > > concerned about a change in nfs-common breaking something semi essential > > that has worked for ages, accidentally or not. > > I'm a bit unsure why this suddenly started going to debian-devel; I'm Cc-ing > the bug again, at least. > > > If something like that is reported, IMHO the only correct course of action > > is first to make sure that the breakage is fixed, and then to start > > talking with maintainers of other involved packages about the correct > > structural fix and migration path, and only implementing your own change > > again _after_ other packages have made the necessary modifications. > > The question here is: When initscripts is broken, and a new version of > nfs-common exposes that breakage, what is the right course of action? I'd say > it is to fix initscripts. Note that this is not a simple code change in > nfs-utils; it is a major move of functionality from one code base > (util-linux) to a different one (nfs-utils). > > Try this patch: Doesn't work in addition to nfs-common 1.1.0-9. Elimar -- Excellent day for drinking heavily. Spike the office water cooler;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#427680: RFH: moc -- ncurses based console audio player
On Tue, 05 Jun 2007 the mental interface of Elimar Riesebieter told: [...] > Is someone out there to give me a hint? Done with flac 1.1.4-2. Thanks Joshua ;) Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427680: RFH: moc -- ncurses based console audio player
Package: wnpp Severity: normal I request assistance with maintaining the moc package. The package description is: moc (music on console) is a full-screen player designed to be powerful and easy to use. . Supported file formats are: MP3, OGG Vorbis, FLAC, WAVE, SPEEX, Musepack (MPC), AIFF, AU, WMA (and other less popular formats supported by libsndfile). New formats support is under development. . Other features: simple mixer, colour themes, searching the menu (the playlist or a directory) like M-s in Midnight Commander, the way MOC creates titles from tags is configurable, optional character set conversion for file tags using iconv(), OSS or ALSA output. . Homepage: http://moc.daper.net As reported in #427473, with no response yet, I want to build moc against new libflac-dev. Configuring the source gives: ... checking for libFLAC... yes ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ... This is shown on a pbuild as well. Configuring against libflac-dev 1.1.2 gives no ERROR. Any way, the package builds fine with libflac-dev 1.1.4, but I don't want to upload with the above config ERROR. Is someone out there to give me a hint? Thanks for cooperation. Elimar -- The path to source is always uphill! -unknown- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is flac still maintained?
On Tue, 29 May 2007 the mental interface of Steinar H. Gunderson told: [...] > /* Steinar */ > - who gave up waiting for flac and compiled it himself :-) Me too ;) But look: I am maintaining the poor console player moc. I wnat to provide it with actual interfaces. Elimar -- Experience is something you don't get until just after you need it! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is flac still maintained?
On Tue, 29 May 2007 the mental interface of Joshua Kwan told: > On Tue, May 29, 2007 at 09:25:46PM +0200, Elimar Riesebieter wrote: > > does one know if the projects maintained by Joshua Kwan are still > > in progress? For instance I am waiting for flac 1.1.4 (#411311, 100 > > days old!) > > I'm on it. I just got done with finals a week or so ago, please be > patient. I'll announce the library transition procedure soon. Thanks Elimar -- The path to source is always uphill! -unknown- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is flac still maintained?
Hi, does one know if the projects maintained by Joshua Kwan are still in progress? For instance I am waiting for flac 1.1.4 (#411311, 100 days old!) Elimar -- >what IMHO then? IMHO - Inhalation of a Multi-leafed Herbal Opiate ;) --posting from alex in debian-user-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416862: O: mutt-ng
Package: mutt-ng Severity: normal I hereby want to orphan mutt-ng as ist isn't maintained upstream anymore [0]. To synchronise the package with mutt and fix the new and upcoming security issues isn't my intetion as I then have to carry over the upstream work. [0] http://mutt-ng.supersized.org/ The best would be to remove it out of the pool as it actually only resides in experimental. It was a great idea to create a mutt by user-wishes. but I think mutt 1.6 will be a well featured one and hopefully the sidebar patch will be adoptet by upstream or at least by the mutt maintainers? Thanks Andreas Kremmair <[EMAIL PROTECTED]>, Rocco Rutte <[EMAIL PROTECTED]> and Nico Golde <[EMAIL PROTECTED]> for their great work to the package. Elimar -- Numeric stability is probably not all that important when you're guessing;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "~" in builddirs caused libtool to fail
On Sun, 24 Sep 2006 the mental interface of Kurt Roeckx told: > On Sun, Sep 24, 2006 at 04:26:16PM +0200, Elimar Riesebieter wrote: > > > > # libtool --version > > > > ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 > > > > 22:14:06) > > > > > > That's what you have installed in /usr/bin, try: > > > ./ld10k1/libtool --version > > > > ltmain.sh (GNU libtool) 1.5 (1.1220.2.1 2003/04/14 22:48:00) > > > > Ok, this is the bug in alsa-tool-1.0.12rc1. I copied `which libtool` > > into ./ld10k1 and everything went well ;) > > That's not the proper way to update your libtool version. You'll need > to run atleast libtoolize, aclocal and autoconf. ## DP: Full relibtoolisation, generated by: ## DP: libtoolize -f -c && aclocal-1.9 && (cp config.sub and ## DP: config.guess from autotools-dev) && ## DP: autoconf && automake-1.9 && ## DP: rm -rf config.sub config.guess autom4te.cache. Elimar -- Do you smell something burning or ist it me? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "~" in builddirs caused libtool to fail
On Sun, 24 Sep 2006 the mental interface of Kurt Roeckx told: > On Sun, Sep 24, 2006 at 03:32:26PM +0200, Elimar Riesebieter wrote: > > On Sun, 24 Sep 2006 the mental interface of > > Kurt Roeckx told: > > > > > > The current version in Debian unstable has: > > > ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) > > > > > > The patch mentioned in the mail says it's last modified 2003-03-24, > > > I've tried building with a ~ in the path and it worked, so I have no > > > idea what's wrong. > > > > > > Elimar, could you check what version of libtool you're using, > > > and what happens exactly? Are you sure this is a libtool problem? > > > > # libtool --version > > ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 > > 22:14:06) > > That's what you have installed in /usr/bin, try: > ./ld10k1/libtool --version ltmain.sh (GNU libtool) 1.5 (1.1220.2.1 2003/04/14 22:48:00) Ok, this is the bug in alsa-tool-1.0.12rc1. I copied `which libtool` into ./ld10k1 and everything went well ;) > > Trying to build alsa-tools-1.0.12~rc1: > > > > ranlib /source/alsa/svn-pkg-alsa/tarballs/alsa-tools-1.0.12 > > ranlib: '/source/alsa/svn-pkg-alsa/tarballs/alsa-tools-1.0.12': No such file > > rc1/debian/tmp/usr/lib/liblo10k1.a > > ../libtool: line 5985: rc1/debian/tmp/usr/lib/liblo10k1.a: No such file or > > directory > > > > The builddir is indeed > > /source/alsa/svn-pkg-alsa/tarballs/alsa-tools-1.0.12~rc1 > > I get: > ranlib /usr/src/alsa-tools-1.0.12~rc1/debian/tmp/usr/lib/liblo10k1.a fixed now > Which seems to be working perfectly. I don't get any errors at all. > > What shell are you using, and what is /bin/sh pointing to? bash. The shel I am running the build with is zsh. Thanks Elimar -- On the keyboard of life you have always to keep a finger at the escape key;-) pgpLVwCvZz3cp.pgp Description: PGP signature
"~" in builddirs caused libtool to fail
Hi all, the new "~" in packagenames and builddirs doesn' fit well. The problem is caused by the fact that there is a "~" in the directory name. Libtool uses "~" as a separator. [1] Is there a way to avoid this or should we use the "old" packagenames -> alsa-tools-1.0.12+1.0.13rc2 instead of alsa-tools-1.0.13~rc2 ? [1]http://autoconf-archive.cryp.to/patch_libtool_changing_cmds_ifs.html Thanks for cooperation Elimar -- Numeric stability is probably not all that important when you're guessing;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sun, 17 Sep 2006 the mental interface of Russ Allbery told: > Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > > [Mario Holbe] > > >> So, as long as the Debian policy doesn't handle this, > > > I agree that we should update the policy to document this fact. > > It would be quite nice to have more people participating in the Policy > process in general. There are a fair number of proposals, but not a lot > of people reading proposals, helping achieve consensus, and seconding. > For example, I haven't gotten any responses to my patch to document ~ in > version numbers, and I'm not sure what happened to the menu policy > overhaul. I've experienced problems using "tilde" in Filenames: The problem is caused by the fact that there is a "~" in the directory name. Libtool uses "~" as a separator. [1] [1]http://autoconf-archive.cryp.to/patch_libtool_changing_cmds_ifs.html Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Thu, 06 Jul 2006 the mental interface of Daniel Baumann told: > Elimar Riesebieter wrote: > > are there any activities on that project? > > The licensing of cdrtools is/was under investigation of the Technical > Comitee, a final decision/action is not yet found/published so far. > > For the public part of the information, read on at > http://bugs.debian.org/350739 Ahh, I didn't noticed this bug. But it shows the way Joerg is discussing with Linux guys everywhere. [...] > > Will the package be orphande next time? > > No, depending on the outcome of the licensing issues, either the current > maintainers still continue to maintain the package, or it has to be > removed from Debian completely. IMHO we have to have a GPL'd package. But at the moment I haven't any clue which alternative we have? Joerg is very sensible and for me it is not easy to follow the discussion between Joerg and Blade, but in summary no one gets sensible for the arguments of the other one. Thats not a good assumption to clarify and satisfy both parties. BTW, the cdrtools are very good ones, to give users very easy intuition to burn, create ISO's or grab ogg's ion both command line and gui frontends :) Elimar -- Numeric stability is probably not all that important when you're guessing;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cdrtools
Hi all, are there any activities on that project? There is no mailinglist active at https://alioth.debian.org/projects/pkg-cdrtools/ and the latest cvs-entry is about 3 months ago or so. Meanwhile we have ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a10.tar.gz # apt-cache policy cdrecord gives: cdrecord: Installed: 4:2.01+01a03-5 Candidate: 4:2.01+01a03-5 Version table: *** 4:2.01+01a03-5 0 500 ftp://ftp.de.debian.org testing/main Packages 990 ftp://ftp.de.debian.org unstable/main Packages 100 /var/lib/dpkg/status which is full of bugs. Will the package be orphande next time? Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xmcd
On Sun, 18 Dec 2005 the mental interface of adrian told: > On Sun, Dec 18, 2005 at 15:40:46 +0100 (+0100), Elimar Riesebieter wrote: > > On Sun, 18 Dec 2005 the mental interface of > > adrian told: > [snip] > > > Hi, sorry for not responding earlier, I've less and less time for > > > Debian stuff as time goes by (busy). There are substantial changes > > > upstream in v3 - not least of which involves some distinctly non-free > > > add-ons. > > > > Do you mean the cdda-gracenote stuff? mp3- and faacencoding can be > > suppressed while buildtime. > > Yep. I hadn't investigated it fully, just marked it as a concern. > xmcd also seems to be a bit clunky cf some other players out there. > OTOH I suppose it supports some hardware that others don't (jukeboxes > mainly). Hmm, to build the CDDB² we have to use the only as binaries available http://www.ibiblio.org/tkan/download/cddb2supp/3.3.0/lib/linux-x86-libc5/cddb2supplib.tar.gz but we won't ;) The pure cddb as in versions 2.* is used by http://www.ibiblio.org/tkan/download/xmcd/3.3.2/src/xmcd-3.3.2.tar.gz so I don't see a reason to not upgrade the package yet? Could someone please check xmcd from my small repos at deb http://www.lxtec.de/debarchiv binary-i386/ deb-src http://www.lxtec.de/debarchiv sources/ It is build without lame and faac encoding yet, but why not? Elimar -- Excellent day for drinking heavily. Spike the office water cooler;-)
Re: xmcd
On Sun, 18 Dec 2005 the mental interface of adrian told: > On Sun, Dec 18, 2005 at 01:28:18 +0100 (+0100), Elimar Riesebieter wrote: > > On Sun, 18 Dec 2005 the mental interface of > > Matthew Palmer told: > > > > > On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote: > > > > does one know why xmcd isn't upgraded since 31 of May in 2003? The > > > > package is neither orphaned nor up for adoption, which I would do > > > > then. > > > > > > Have you asked the maintainer, Adrian Bridgett? He's around (last made an > > > upload less than a month ago, for tkdiff), so I don't see why he wouldn't > > > be > > > able to give you a reasonable answer to your question. > > Done. > > Hi, sorry for not responding earlier, I've less and less time for > Debian stuff as time goes by (busy). There are substantial changes > upstream in v3 - not least of which involves some distinctly non-free > add-ons. Do you mean the cdda-gracenote stuff? mp3- and faacencoding can be suppressed while buildtime. Elimar -- The path to source is always uphill! -unknown- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xmcd
On Sun, 18 Dec 2005 the mental interface of Matthew Palmer told: > On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote: > > does one know why xmcd isn't upgraded since 31 of May in 2003? The > > package is neither orphaned nor up for adoption, which I would do > > then. > > Have you asked the maintainer, Adrian Bridgett? He's around (last made an > upload less than a month ago, for tkdiff), so I don't see why he wouldn't be > able to give you a reasonable answer to your question. Done. Elimar -- Experience is something you don't get until just after you need it! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xmcd
Hi, does one know why xmcd isn't upgraded since 31 of May in 2003? The package is neither orphaned nor up for adoption, which I would do then. Elimar -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342039: ITP: ripit -- Textbased audio cd ripper
Package: wnpp Severity: wishlist Owner: Elimar Riesebieter <[EMAIL PROTECTED]> * Package name: ripit Version : 3.4.0 Upstream Author : Felix Suwald <[EMAIL PROTECTED]> * URL : http://www.suwald.com/ripit * License : (GPL) Description : Textbased audio cd ripper runs in text mode (no fancy GUI here) and does everything required to produce a set of mp3, ogg, flac, m4a files without any user-intervention. . ripit does the following with an Audio CD: - Get the audio CD Album/Artist/Tracks information from CDDB - Rip the audio CD Tracks (using cdparanoia or other cdrippers) - Encode the files (using lame, oggvorbis flac and/or faac) - ID3 tag them (v1 & v2) - Optional: creates a playlist (M3U) file (lists MP3s created, used by various MP3 players) - Optional: Prepares and sends a CDDB submission. - Optional: Saves the CDDB file. Lintian clean packages: deb http://www.lxtec.de/debarchiv binary-all/ deb http://www.lxtec.de/debarchiv binary-powerpc/ deb http://www.lxtec.de/debarchiv binary-i386/ deb-src http://www.lxtec.de/debarchiv sources/ Thanks Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche pgpTKjHkfH26t.pgp Description: PGP signature
libvorbis and vorbis-tools
Hi all, is Christopher L Cheeney submerged? There are new upstreamversions of libvorbis and vorbis-tools available which fix a lot. Elimar -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#331642: RFH: fetchmail -- SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
Hi Nico, On Tue, 04 Oct 2005 the mental interface of Nico Golde told: > Package: wnpp > Severity: normal > > Hi, > I am searching for a new Co-maintainer for fetchmail since > Goswin von Brederlow and Lucas Wall don't have much spare > time anymore and the next release of fetchmail doesn't seem > to be far away. Isn't the development of fetchmail is stopped since 10/2003? Of course yes, this is the date of the last upstream. ELimar -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds pgpTPHZHznxcX.pgp Description: PGP signature
Re: curl status update
On Sun, 02 Oct 2005 the mental interface of Paul TBBle Hampson told: > On Sat, Oct 01, 2005 at 02:43:32PM +0200, Elimar Riesebieter wrote: > > On Thu, 29 Sep 2005 the mental interface of > > Steve Langasek told: > > > [...] > >> There isn't? I saw some arguments that explain why it's not possible to > >> convert all curl-using applications from OpenSSL to GNUTLS without a > >> recompile due to unavailable ABI changes, but I thought it was pretty clear > >> that the default going forward should be the one whose license is maximally > >> compatible with that of applications using libcurl (i.e., GNUTLS). > > libcurl3-gnutls-dev 7.14.1-3 works well ;-) The only challange we > > have to solve is: > > Which curl deps have to be the default? > > IMHO the gnutls one. > > What do you mean by default? libcurl has to point to gnutls by default! Elimar -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: curl status update
On Thu, 29 Sep 2005 the mental interface of Steve Langasek told: [...] > There isn't? I saw some arguments that explain why it's not possible to > convert all curl-using applications from OpenSSL to GNUTLS without a > recompile due to unavailable ABI changes, but I thought it was pretty clear > that the default going forward should be the one whose license is maximally > compatible with that of applications using libcurl (i.e., GNUTLS). libcurl3-gnutls-dev 7.14.1-3 works well ;-) The only challange we have to solve is: Which curl deps have to be the default? IMHO the gnutls one. Elimar -- >what IMHO then? IMHO - Inhalation of a Multi-leafed Herbal Opiate ;) --posting from alex in debian-user-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#325643: libcurl and moc
Hi all, I bounced this message to debian-devel to force a solution with the curl ssl/gnutlds diverties. On Tue, 30 Aug 2005 the mental interface of Daniel Stenberg told: > Hi > > The problem you have with libcurl and OpenSSL/GnuTLS is not strictly an > "upstream problem". > > In the curl project there are some ideas floating around that are being > discussed on how this could be fixed for Debian (and other distros) but that > is > only because they don't do it themselves, it is not because it is an actual > problem in the curl camp. It is more of an indirect annoyance. > > Also, discussions are only talk. There is no fix or solution in the work for > the nearest period of time. Everyone's invited to come help sort it out. > > In my view, there's only one available work-around for the short to mid term, > and that is to use a separate .so file for libcurl built with GnuTLS. My resume on Daniels point of view is to get a different .so name for gnutls in the very short term and kick off ssl in Debian apps midterm! Note, this will _not be done upstream_! This is not as hard as Marco's demand, but we have to do it in that way. There are some curl based packages like oggvorbistools, moc etc which are at the moment uninstallable and herewith I invite Domenico to provide a package where gnutls and ssl can exist beside in one installation. For me, as a not much experienced voluntary I'll spend some spare time to understand the technique on how to do that and hopefully can assist Domenico to create a package. Hugh Elimar -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: incoming
On Mon, 29 Aug 2005 the mental interface of Elimar Riesebieter told: > Hi all, > > is there a reponsible person for cleaning up the cadavers in > incoming? If yes, could you you please do so? Don't found a severity > for that in the BTS. > > The oldest entry is from > oops_1.5.19.cvs.20010818-0.1woody1_ia64.changes 20-May-2005 04:32 $ lynx -dump incoming.debian.org | tail -1 196. http://incoming.debian.org/zlib_1.2.2-4.sarge.2_s390.changes Is that the new Debian cemetery ;-) This is after upload. The youngest entry at the moment is Report. Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: incoming
On Mon, 29 Aug 2005 the mental interface of Nico Golde told: [...] > Mail to the ftpmasters team. Thread start forwarded. Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
incoming
Hi all, is there a reponsible person for cleaning up the cadavers in incoming? If yes, could you you please do so? Don't found a severity for that in the BTS. The oldest entry is from oops_1.5.19.cvs.20010818-0.1woody1_ia64.changes 20-May-2005 04:32 Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: curl reverts to openssl (but the story does not ends here)
On Sat, 06 Aug 2005 the mental interface of Domenico Andreoli told: > reopen 318590 > thanks > > hi dear developers, > > it looks like i completely underestimated the transition of curl > to gnutls [0]. so i have just made a new upload which settles > the things back to openssl. Bad idea to switch to ssl only :( > i don't want to start any transition right now, also because > upstream developer made me note that the gnutls support is still > young. But still works ;-) > these are bad news for those gpl packages waiting for libcurl with > no openssl. they will have to wait a little more. i'm sorry for > this. It is quit easy to create separated gnutls-packages. > in talking about the solution IMHO things get hotter. ? > probably the next simpler solution is to add libcurl3-gnutls and, > if required, libcurl3-gnutls-dev packages. but somebody could > prefer a -nossl version (like that still in woody, the one i > should have never removed). Readd it! [...] > i continue to think that having only a curl+gnutls package is the > long term solution but i'll be glad to hear also your opinion and > suggestions. [1] Should be short term. As mentioned many times before, do it ;-) [...] > [1] yes, recently a thread talked right about curl and openssl vs. > gnutls, but evidently i didn't see what i call a general > consensus. IMHO provide both, ssl and gnutls. Elimar -- It's a good thing we don't get all the government we pay for. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, 18 Jul 2005 the mental interface of Domenico Andreoli told: [...] > i doubt seriously a new package like libcurl3-gnutls is appropriate, > but let me know your opinion. > > is this stuff urgent? Yes! Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Wed, 20 Jul 2005 the mental interface of Marco d'Itri told: > On Jul 20, sean finney <[EMAIL PROTECTED]> wrote: [...] > i know i'm repeating myself here, but the real fix is to politely > > solicit the upstream author to change or add a clause to their license > > that makes such allowances. that, or change the build options of the > No, the real fix is to convert as many programs as possible from openssl > to gnutls, starting with libraries. Right, let's start! Elimar -- Experience is something you don't get until just after you need it! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3?
On Mon, 18 Jul 2005 the mental interface of Torsten Landschoff told: > Hi Goswin, > > On Mon, Jul 18, 2005 at 01:06:01PM +0200, Goswin von Brederlow wrote: > > > I guess the savest way is to have a libldap-nossl-dev and > > libldap-ssl-dev. The former should have anything ssl derived > > removed. > > No problem. But then I can just build libldap without ssl as the library > built without SSL puts macros into the header files to disable ssl > functionality iirc. In summary: libs linked again ssl need at least two dev-packages: libfoo-dev.deb and libfoo-ssl-dev.deb Right? Should it be worst to announce this to debian-devel-announce? Elimar -- Obviously the human brain works like a computer. Since there are no stupid computers humans can't be stupid. There are just a few running with Windows or even CE ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, 17 Jul 2005 the mental interface of sean finney told: > On Sun, Jul 17, 2005 at 08:21:00PM +0200, Elimar Riesebieter wrote: > > I don't see a gpl'd alternative to curl for internet streaming. I am > > thinking about to build moc --without-curl then :( > > or you could always contact the author and inform them of their > self-inflicted license violation. in my experience, many authors > don't realize the licensing problem and are more than willing to > relicense/dual license/add exceptions for stuff like openssl. > > > What about the fbi-package, raptor-utils-package and others who are using > > libcurl3 as well? > > if they are strict gpl and use libcurl, you should report bugs against them. apt-get remove --purge libssl0.9.7 gives me tons of packages. Just an estimation: We need to repack half of all packages then? Elimar -- Planung: Ersatz des Zufalls durch den Irrtum. -unknown- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, 17 Jul 2005 the mental interface of sean finney told: > On Sun, Jul 17, 2005 at 08:21:00PM +0200, Elimar Riesebieter wrote: > > I don't see a gpl'd alternative to curl for internet streaming. I am > > thinking about to build moc --without-curl then :( > > or you could always contact the author and inform them of their > self-inflicted license violation. in my experience, many authors > don't realize the licensing problem and are more than willing to > relicense/dual license/add exceptions for stuff like openssl. > > > What about the fbi-package, raptor-utils-package and others who are using > > libcurl3 as well? > > if they are strict gpl and use libcurl, you should report bugs against them. Damian can't. I asked him. Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a NMU? Elimar -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, 17 Jul 2005 the mental interface of Marco d'Itri told: > On Jul 17, Elimar Riesebieter <[EMAIL PROTECTED]> wrote: > > > comfortable to build curl against gnutls in general? Any hints? > Upstream developers should get a clue and either properly license their > software, stop using libcurl or adding gnutls support to it. I don't see a gpl'd alternative to curl for internet streaming. I am thinking about to build moc --without-curl then :( What about the fbi-package, raptor-utils-package and others who are using libcurl3 as well? Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libcurl3-dev: A development package linked again gnutls needed
Hi, I am currently maintaining moc, a _m_usic _o_n _c_onsole player: http://moc.daper.net apt-cache show moc The new version 2.3.0 needs libcurl-dev, 'cause streaming is possible now. Start using libcurl, which depends on libssl, and since GPL is incompatible with OpenSSL license, the package was rejected upstream. Checking the source of curl-package it is possible to build curl --without-ssl and --with-gnutls=/usr. Should we have a libcurl3-dev and a libcurl3-ssl-dev package or ist it more comfortable to build curl against gnutls in general? Any hints? BTW, I filed #318590 with no response 'til yet :( Elimar -- Numeric stability is probably not all that important when you're guessing;-) pgpOh2BC5vlD8.pgp Description: PGP signature
Re: GCC version change / C++ ABI change
On Sun, 03 Jul 2005 the mental interface of Matthias Klose told: > This week, we will change the GCC default versions from 3.3 to 4.0 Do we have to put CFLAGS += -Wno-pointer-sign by default to each rules file? Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
On Thu, 24 Mar 2005 the mental interface of Paul Hampson told: > On Wed, Mar 23, 2005 at 08:53:38PM +0100, Per Olofsson wrote: > > Elimar Riesebieter: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Elimar Riesebieter <[EMAIL PROTECTED]> > > > > * Package name: mutt-ng > > > Also note that Norbert Tretkowski has already created a mutt-ng > > package, although he doesn't intend to upload it (yet). It is > > available at <http://people.debian.org/~nobse/debian/unstable/>. > > Actually, the site with the test deb files mentions that Norbert > has passed the baton to Elimar. > > On the other hand, I'm having a problem with the package, it > doesn't include muttng_dotlock, and seems to think my mailspool > (mbox in /var/mail) is read-only. (vanilla) Mutt can use it > fine. On the machine the i386-build was done, /var/mail was world-readable (don't flame me), so configure seemed to not build dotlock then. Will be fixed next upload (maybe tonight). Elimar -- Numeric stability is probably not all that important when you're guessing;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
Package: wnpp Severity: wishlist Owner: Elimar Riesebieter <[EMAIL PROTECTED]> * Package name: mutt-ng Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Mutt next generation (mutt-ng) is a fork of the well-known email client mutt (Include the long description here.) Mutt next generation (mutt-ng) is a fork of the well-known email client mutt with the goal to both incorporate all the patches that are floating around in the web, and to fix all the other little annoyances of mutt. . Differences between mutt and mutt-ng: o Better view support for format=flowed attachments o Message IDs are configurable o User can set signoff_string just like in slrn o User can call up the "last folder" when saving attachments o IMAP reconnecting: when the connection to the IMAP server dies, mutt-ng attempts reconnecting o User can set the umask with which all the files shall be created (was hard-coded before, and caused huge problems for shared mailboxes to some people) o Support for NNTP, i.e. mutt-ng can be used as a newsreader o A sidebar similar to other (graphical) MUAs where you can directly jump to a certain mailbox -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11.5-frodo Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) mutt-ng is an incredible solution on top of the famous mutt mailer. Please feel free to test the Debian mutt-ng binaries found at http://www.lxtec.de/debarchiv/sources/mutt-ng/ which incudes further information as well. http://www.mutt-ng.org Ciao Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) signature.asc Description: Digital signature
